//TODO: Create Blog Title

Eric Nelson and a team of 15 developers (including myself) have pulled together a free eBook covering some of the possibilities and techniques when developing with the Windows Azure Platform. The eBook is available as a free PDF download and can be viewed on SlideShare as well. If you are interested in how the collaborative journey came along check out Eric’s post.

The two articles that I authored are: Implemented a Distributed Cache Using Worker Roles and Building a Content Based Routing Service.

We will be writing a second volume later this year and potential ideas for new articles are welcome!

NAIDCharities (a charity that a friend of mine runs) is giving you the opportunity to support a great cause that helps find placement for abandoned animals by holding a 2011 Dodge Challenger SRT8 raffle.

Tickets are $20 and limited to no more than 5,000. An additional early bird drawing will take place on Tuesday, August 31 for many different cash prizes. The grand prize drawing is on Thursday, December 30.

Follow @naidcharities on twitter or become a fan of NAIDCharities on Facebook.

Fail

A certain way to ensure failure on any software development project is to manipulate a team members’ view of what defines success for the feature/application. Any time new features are getting implemented (per requirement) ask the following questions:

• Does this provide reusability in other areas of the application?
• Is it horizontally scalable?
• Is it interfaced in case you need to use a different implementation?
• Is the code portable on different platforms with no changes?

If the answer is no to any of the above questions, then there hasn’t been enough planning for the feature. Don’t worry about conserving time and delivering sooner. Focus on building for all possible scenarios even if requirements don’t call for it (you never know)!

Resolution

Have you ever been involved with a team member who felt every piece of code in the system had to be extensible, interchangeable, self healing, or scalable? It seemed that requirements that were not even the concern of the project sponsors were always in this particular team member’s mind while writing or critiquing code.

As in any construction project, there must be a vision or definition of what is to be built.

If the “box” is the boundary of constraints and conditions, then the trick is to find the box… Don’t think outside the box—find the box.

- Andy Hung and Dave Thomas in Code Complete: A Practical Handbook of Software Construction

Treat the development of software like evolution (if you believe in it). Humans didn’t develop overnight. Millions of iterations took place and feedback (aka survival of the fittest) was provided to determine the best solution.

* DISCLAIMER * Please note that Friday Failure is meant to provide humor at what can go wrong when poor development practices are used. I’ve likely made this mistake plenty of times in my career.

In the last few years, I have interviewed a number of college students and graduates (Computer Science) and recognized an obvious deficiency in real world skills. While most have gathered details on how to work independently and discipline themselves to learn, the students lack exposure to life outside of a classroom. Those that understand stand to perform better since they are familiar with expectations.

What can the other candidates do to improve their chances of landing a decent job straight out of school?

…But I Have Straight A’s

Straight A’s will not make you a CEO, only a great entry level employee. Straight A’s means you are great at doing assigned work. Leading a company requires social skills, vision, and creating work when there is nothing tangible there.

– Ryan Healy in 8 On-The-Job Rules You Unfortunately Can’t Learn in College

Note: I am not making excuses if to not finish the curriculum. Put some effort in and you will be out soon enough. After all… I made it.

Traditionally in academics, we provide you problems that teach core concepts: object-oriented programming, data structures, proper database design, etc. Beyond that we need to foster the ability to perform independent thought and collaborate. You should receive an overview of software design patterns, when and where it is OK to sacrifice quality for the sake of performance, or to how to make accommodations to meet a deliverable.

The real world is much more open-ended. You are responsible for the decisions you make. Did you make a design decision that supports reusability? Does the design pattern hinder the ability of the application to extend beyond its initial scope?

Defining your own design, also requires you to sell that design. If no one else is biting, most likely it’s a bad decision or was explained poorly. Not everyone will agree and will find points of design failure. Expect that. Your ability to mitigate failures those will improve with experience.

Requirements?… Check

Requirements always change from start to finish of a project. Be prepared to be told your release date has been moved up a week or you are responsible for an entirely new set of features. How does this impact your current work to date? Do you need to modify your design without a complete rewrite? You may also be forced into a negotiation for what features are important enough to hit deadlines and which can be left out.

Twenty-One Year Old Looking for Solution Architect Position

Leading teams of one or two does not qualify you lead developer. No developer position in college prepares you for the pressure of the role of solution architect, responsible for multiple implementations and ensuring teams have a clear understanding. You will not know how to manage until you really manage.

Instead focus on team player skills. Work on an open-source project. Build a solution that solves a problem. Leadership skills are identified when you state, “I took ownership of building the flux capacitor by proposing a design to the rest of the team, and after some discussion, built a proof of concept and focused on integrating with the solution.”

Coding by the Book

Working with teams will get you exposed to other developers’ source code. When you went through your introduction courses, everyone was taught to code using the same standards. Just like fashion, people change coding styles over time. Stop reformatting their code to follow your standard and evolve a set of standards that the team will adhere to.

Stop Wasting Time Rewriting Existing Code

Moving into my last point, it is important that you build core understanding of basic data structures and OOP. Once that foundation has been laid, in the real world, you need to focus on using external libraries, and code that has already been written. Understand how frameworks are designed, how to integrate with third party components, and when not to reinvent the wheel. While doing this, you will easily see that there are many different styles (interaction, development, standards) that other authors use. In doing so, you may create your own unique development style.

As a last point, the following are skills I was not taught in college that are important to understand post-classroom:

• Developing simple reusable libraries
• Web services
• Proper exception handling
• Debugging techniques
• Writing unit tests
• Revision control and source merging

What do you think students stand most to understand before entering the workforce?

I have used the Entity Framework for two successful project implementations. In my opinion EF lies somewhere between "awesome framework that makes application development a breeze" and "generic tool that requires too much effort to do anything besides out of the box".

Before I explain myself, I need to identify the common patterns I think are necessary in any application that needs to persist data:

EF works to simplify the development for database dependent applications by removing the redundant work involved in each project. Namely, the below highlighted tasks:

What is so bad about Entity Framework?

1. Most developers do not know to optimize database operations. EF creates a sandbox so that they may do whatever the hell they want with the data. This will drive any DBA crazy when they are asked to make optimizations.
2. With 99% confidence, I believe that most of the .NET framework code is bug-free (or has yet to become a problem for me). Knowing this, we can believe that our EF SQL queries are probably legit. But isn’t it important to test our queries themselves through unit tests? The ability to unit test our own data access methods without requiring an active database (in-memory or XML defined?) is a necessary feature.
3. Consequently, the application is fully aware of the ties to the EF and cannot be tested without. Persistence ignorance support is necessary so that developers are not forced to implement additional interfaces or provide unnecessary references.
4. Developing N-Tiered Applications with EF is difficult. Reattach objects into the data context after client modifications requires too much work.
5. Lazy loading improves performance, but excess code is needed to check if a related set is loaded. If it is not loaded, additional code is required to perform the operation. Consequently, it could make database operations unnecessarily chatty.

I am only able to list five points about what is bad about the EF, after working on it for 8 months. In that time I have managed to work around two of the five issues with ADO.NET Data Services (unit testing data access methods with a mock implementation and creating N-Tiered applications). Performance issues have cropped up that I am 100% confident would not exist if custom code had been written to manage data access.

So what is the ‘Entity Framework Balloon’?

Someone once provided this analogy to me.

If our project were a water balloon, each development task would have its own piece of space. The introduction of EF attempts to shrink the cost/time to do the redundant tasks by compressing that side of the balloon. But the other tasks have to go somewhere else, and their piece just gets bigger and requires more effort in the long run.

There always seems to be a new tool for the job. EF obviously serves its purpose, but it fails at making everything as easy as it seems.

.NET 4 with the new Entity Framework

Looking ahead, the ADO.NET Team Blog has focused on a list of concerns for the next version of EF.  They are focusing on improving:

1. Enabling settings to make development simpler such as lazy loading, eager loading, and stored procedure mapping.
2. Improving the readability of the generated SQL.
3. Persistence Ignorance support, allowing you to write POCO and later tie them to Entity Framework or another Data Provider.
4. Better N-Tier Support allowing the serialized entities to include their own change tracking properties.
5. Model-First and Code-Only development!
   

    

   Entity Framework Reading List:

   Anti-Patterns to Avoid in N-Tier Applications
   The Entity Framework in Layered Architectures
   What’s New and Cool in Entity Framework 4.0

I just could not resist reposting Scott Hanselman’s most recent post: 2009 Ultimate Developer and Power Users Tool List for Windows.

I am currently waiting for parts to come to rebuild my home machine and install Windows 7 on. I cannot wait to review every item in this list to see if they increase my productivity!

Important lesson for those who prefer using GUIDs as record identifiers.

The MS SQL data type, uniqueidentifier, does not have a counterpart in Oracle. In the past it was easy to make the column CHAR(36), the max string length of a GUID. I was not in a situation to do this as we were dealing with the Entity Framework against Oracle. 

Entity Framework is compatible with SQL Server out of the box and translates the uniqueidentifier column to GUID type. This is not the case for Oracle. The use of a third party adapter, dotConnect for Oracle, is required. This provider requires that the storage data type for GUID be RAW(16).

What’s the problem with RAW(16)?

GUID representation

{922B0A87-7A88-DE11-BBA7-0AEA0522E79F}

RAW(16) representation

870A2B92887A11DEBBA70AEA0522E79F

As if it was not tough enough already to read and write a GUID. Now it is represented differently in Oracle!!??

The best solution that I discovered to get around this was through the use of a handy GUID Converter. I don’t know how many times I have relied on this to help me out.

1. Setters that do more than SET

All property setters should validate their input and set the value of other properties. This will remove the burden of validation from other developers.

Workaround: Property getters and setters should only save and return values. Getters and setters should not validate against null, perform regular expression checks, or typecast. Additional logic can take place in business logic classes. Setters that do more than set also cause issues during unit testing. What goes in, must come out.

2. The Golden Hammer

Whenever implementing something new, remember the last successful (or similar) experience and reuse.  There is no doubt about it. What worked for you in the past, will continue to work for you now.

Workaround: With the Golden Hammer approach, your solution is the hammer and every project you come up against is a nail. If you find yourself trying to implement an exact replica of a solution that you built in the past, chances are that you will miss some requirements or pigeonhole yourself into somewhere you do not want to be. Instead, step back, learn what the functionality of the system must be, and compare/contrast the differences between past experiences.

3. Swiss Army Class

Just as in bloated class, minimize how many separate classes your code must deal with. If you know all of the different functional areas your application needs to cover, extract them to an interface. Using interfaces will allow you to switch out the implementation types without changing your code. Just make sure that you keep your number of implementation classes low so that it is more maintainable. If necessary, make the lone class implement every interface in the project.

Workaround: Focus on keeping the implementation of your classes very specific to single units. If you feel the need to implement multiple interfaces to create a hybrid of a few simple interfaces, this is perfectly acceptable.

4. Yet Another Damn Layer

Encapsulation is one of the greatest features of object oriented programming. If you can find a way to make existing code more generic so as to make it easier for implementation efforts (and less code writing!) you should do so. Create a generic interface that will take care of defining all of the different functionality in one call.

Workaround: Encapsulation should be used to hide any of the internal mechanisms of a separate software component. Good examples of this are code that is used to perform common tasks such as logging, serialization, or instrumentation metrics.

5. Unit Testing and Stale Data

Since testing is usually a hassle to go through, try and spend as little time doing it as possible. It already takes long enough to set up the tests and the test data. Try not to worry about clearing out the test data since it is only in the development environment.

Workaround: Unit tests should take care of setting themselves up and tearing themselves down. Unit testing should and can be a full-time job position as it should account for every possible variation of data input and output that can occur. If you can not write your unit tests to clean their test data up, then they should use in-memory data providers so as not to impact any other users in the same environment.

* DISCLAIMER * Please note that my views are that of the Workaround type method and this article is meant to prove humor at what can go wrong when unsafe practices are used. Also keep in mind, I’ve probably done each and one of these plenty of times in my career.

It’s 4:00 on Friday afternoon. Do you know where you want to be?

Definitely not at work. About fifteen minutes before you decide to log off and bolt out early, a critical defect is logged with your application. Your data import isn’t working correctly and it is losing content during execution. The client, and project managers stress to you that this is a must fix issue as the testers cannot continue until your content is valid.

You grumble, sit back down, and pull up the code to inspect the issue. Ten to fifteen minutes later the fix looks relatively easy. Excited that a resolution was identified so fast, you settle in and begin the fix. Shortly after the fix is in place, you test to make sure everything continues to work as is…. then you gasp as you realize what happens next: it is the Whack-a-Mole bug.

whack-a-mole bug n 1. a defect that reappears throughout your application in multiple locations and is difficult to get rid of no how many times you attempt to get rid of it

Related Code-smells: DUPLICATE CODE, SHOTGUN SURGERY

Most often this code smell is a by-product of Shotgun Surgery. While it may seem easy to copy the same validation code used during data-in to data-out, you know it is not the right choice. Now later on, that specific code had particular issues and it must be fixed in more than one place.

A few months ago I started working on a new home project that I wanted to keep under source control. My only requirement was that it be closed-source as I wasn’t ready to share my idea with the world yet. I am cheap, and I decided to look for a free alternative first before I decided to pay someone. I stumbled upon XP-Dev.com.

What I get with XP-Dev Free:

• Subversion Hosting up to 500 MB
• Unlimited number of Projects
• Wiki Pages
• Blogs & Forums

XP-Dev.com has only suffered one outage since I’ve been with them, and the owner of the site was very vocal with what the status was for getting back online.  For any new projects that you are working on, or if you want to have something under version control, I definitely suggest using XP-Dev.com.