DCSIMG
August 2007 - Posts - .NET Geek

.NET Geek

"It is upon the Trunk that a gentleman works" - Confucius

August 2007 - Posts

How To Finish A Big Software Project And Be The Hero

In a recent post at RealSoftwareDevelopment a list of undeniably important steps to secure your project success are listed. While I find the list comprehensive, an issue came to mind while reading it. In the post they use building a building as an example.

"It's Like Building A Building

Have you ever seen the construction of a building?  Does everyone go into their own little silos and build their own thing?  No!  How is a skyscraper built?  First lay the foundation, then put in floors, with the elevator shafts, then build floor after floor, then the interior, etc.  Could you imagine what would happen if every piece was built in a different site, and then later everything was dropped off at the construction site to be assembled?  Even if you had the best plan to assemble everything together, you would have problems!  Things wouldn't fit and would have to be re-done, architects would change their minds, pieces would be missing, and the building would look like a bunch of match sticks!"

The post then gives a process guidance of how to go about ensuring the building is built right.

Will following these steps help you towards a successful project? Sure!
My problem with the article is that it places too much emphasis on the process. A process is only a means to secure the product. Yes, you need source control, release management, QA etc., but these are all in place to make sure the code your team write works in harmony.

What if your code is crap? OK, not crap. 
What if the code is not easily maintainable. A big project will almost always go through requirements changes and sometimes dramatic code changes.
What if the code is not easily extensible? Can you even perceive every option potentially needed as you write code? Should you? The answers are; no you can't, and no you shouldn't.
What you do have to do is write code that will allow you to make significant changes without ripping the system in part and setting the schedule back 6 months.

So while the process is important it is there to support building blocks of solid code. If the code is of low quality then no process in the world will help you.