There is a legend surrounding the profession of architects that tells of an architect who designed a marvelous library in which he forgot to take into consideration the weight of the books.  This over sight on his part later caused the library to be condemned as the library gradually sank over time.  Although no more than a legend, it brings to light an interesting topic… When we make a decision and influence all of those around me, what if we miss something?

Well, our profession actually has certain check points that have been instituted to prevent such disasters from happening.

1.       Code Reviews:  This one is the most obvious, but code reviews are highly beneficial for both this check, and many others provided they should serve as more than a Hey, you spelled that name wrong purpose.  Code reviews can act as a final check to ensure that the developers are in fact sane in their design, and not off in la la land.

2.       Unit Tests:  This serves more to prevent someone from going in and changing something, and introducing these types of insights.  With a good set of unit tests covering 100% of the testable code, it is very easy to catch these modifications over sights provided the initial design was sound, and tested accordingly.

3.       Test Driven Development:  Simply put, starting with what the users (internal or external to IT) want, and moving backwards to provide the code can help to eliminate this issue as well.  When we code off in our own little worlds, we tend to add tons of edge cases and this could happen scenarios that no users would ever consider.  This is a mixed blessing because as developers we tend to be very detail oriented, and can often conceive of situations that could never happen in real life.

4.       Peer Programming:  Well, two sets of eyes are, and always will be better at catching bugs than one set… it’s that simple.

At the end of the day, this list is just a small portion of the hundreds of ways we’ve attempted to perfect our profession.  Realistically though, there are by far more failed attempts than successful ones at bullet proofing the art of software creation and it always comes down to one thing, the people developing the code.

Let us consider for a few seconds the scenario about the weight of the books again; lets apply this to software development and analyze just what could have been done differently in this situation.

1.       Code Reviews:  Well, sure if the design was reviewed it may have stopped this, but a good architect can sell any design even to other architects no matter how wrong it may or may not be.

2.       Unit tests:  Well simply put the initial design was flawed.  A good set of tests would have actually tested to ensure that the library would sink with the weight of the books, possibly exposing the issue.  Realistically it was never something which was taken out of the design, so no one would have thought to test it either.

3.       Test Driven Development:  I highly doubt the users would have ever thought to question the architect and ask if he had accommodated for the extra weight.  In fact, most architects would be offended if a user had questioned something like that because it is after all, their purpose to find those issues no one else thinks of.

4.       Peer Programming/Design:  Yes, this would have at least doubled the chance of finding this issue in the initial plans, but it could have slipped through to the end still.  Even peer teams are by no means perfect.

So I guess this kind of exposes a bit of an issue… maybe we aren’t as bullet proof as we think we are?  The only real suggestion I can think of is that we need to take that step back and look at the big picture some times, get our heads out of the code and look at the larger impact of the lines we write.  Maybe one line of code at a time, module by module is not really going to solve our problems?  I guess what I’m saying is when you look at the big picture, sometimes the code really is just a small piece of the puzzle…

Recently there has been a lot of talk around my work place about ease of adoption on a software project... essentially how easy is it for someone who has never looked at the code to go into TFS, download the code and run it and the unit tests.  I am a firm believer that I should be able to simply open my source control window, and double click on the solution file.  There shouldn’t be any third party items that HAVE to be installed separately, no libraries that need to be referenced out of the GAC, none of that.  In my eyes, if I have to do any more than a simple double click and run the project is a giant failure.  I mean it, at this point I think it would be appropriate to delete all of your code, and go register yourself back in school because you do not deserve to be developing on an enterprise level.

Now here’s why.

1)      Recently I’ve taken on a new project, and it’s taken me two weeks to find all of the third party libraries that I needed, install them, and configure my machine to actually work with this project and the others I have installed.  This is caused mostly by versioning issues, when the new project is expecting a different version of a DLL than I currently require for something else, who should win?  Well, the second I got it working I pulled everything into a library folder and checked it into our source control.  This took me all of about half an hour to accomplish once I got it working, and if I could have saved myself the previous two weeks or non-sense work I would have greatly appreciated it.

2)      Talking with the developers on the same project as I had all the issues with, they had the exact same problems as I had, and actually listed it as one of their biggest headaches. 

3)      The ability to move the code to a build server.  For those of you who have never had the luxury of using a build server I strongly suggest that you go out and download one such as TeamCity by Jetbrains.  It is one of those things that I’ve just started to use and I could not justify stopping.  It makes deployments as easy as copy and paste.  Also, when you’re working with other developers who might not be as anal about running unit tests as we are, you can set up the build server to automatically run them every time code is checked in.  Guess what that means, no more downloading someone else’ broken code when you get latest!

4)      And finally, why not?  For the half an hour that it took me to fix it, it probably would have taken 20 minutes to do it right the first time...

The most common excuse that I’ve heard in regards to this from other projects is we don’t have the time to do it right, so we made it work the only way we knew how to.  At what point did our profession become more about getting it done, and less about getting it done right?  I’m sorry but I don’t know of a single user that would object if I said I was going to spend an extra half an hour on a three month project to make it so that any changes they ever wanted would take half the time to implement... but maybe that’s just me...