DCSIMG
How To Finish A Big Software Project And Be The Hero - .NET Geek

.NET Geek

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

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.

Comments

Greg Alvord said:

It is a common mistake among novice Project Manger types, that the Process or the Plan becomes the goal rather than part of the path to the goal.  

I believe that you are correct, that ugly code is just as detrimental to achieving the goal as leaving off one of the steps from RealSoftwareDevelopment article.

Process cannot be a substitute for craftsmanship.

Good building come from good craftsmen.

There can be however, other processes to build and support craftsmanship. Craftsmanship will not be attained during the life of a single project. It is a life long process carried out by the individuals. Organizational process can promote a culture for growth of craftsmanship.

# August 19, 2007 2:31 AM

Tariq Mumtaz said:

Yes you are right good code is must. But I am also sire that you can setup a process for code quality management.

# June 22, 2008 4:35 PM

Tariq Mumtaz said:

Please read as follows:

Yes you are right good code is must. But I am also sure that you can setup a process for code quality management also.

# June 22, 2008 4:37 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: