A Tale of Two Systems (Beautiful Architecture - Chapter 2)

What a difference one chapter makes! The second chapter sparked my attention as the topic kind of hit home and reminded me of some development pains I have had with previous employers. Ugh, the horror!!!

Working on a poorly-designed system is like driving a 1978 Chevy Nova that is being kept together by kite string and duct tape. Sure, you can add a new radio or buy new tires, but the car is still being held together by duct tape and is not roadworthy. You could even add an alarm system if that would make you feel better. Eventually, the vehicle is going to succumb to reality and fall apart while driving 65 mph on the interstate. You (and management) really need to take a step back and evaluate if the "car" should be stripped down to the chassis and rebuilt due to a previous poor design. The financial, morale, and personal benefits will be realized immediately.

In this day and age, you are rarely ever going to be the sole architect, developer, tester, and maintenance person. You will always be part of team. The team could be comprised of 4 people or 70 people. The quality of the product is a direct result of how well the team works together. Believe it or not, the buzzword "synergy" plays a strong role in determining the success or failure of the project. A rogue developer, or a group of developers, claiming mutiny could bring a development program to its knees and potentially destroy future business.

It appears this author is a proponent of the extreme programming methodology. There are definite advantages to this approach when there is no definitive path for development. XP forces the architect or developers to work closely with the stakeholder which allows the stakeholder to stay-in-the-loop on progress and help drive the next phase of development. From a developer point of view, pair programming can be very beneficial in spreading the knowledge of the code and functionality to various teams as they each work together on various parts of the project.

If you have not done it before, you would be amazed at how the simple steps of refactoring and unit testing will greatly improve the quality (and inherently the design) of the code. It is quite scary to see what some so-called developers determine as valid or clean code. Maybe it is acceptable if you are going to be the only person updating the code for the next 50 years. Now that would be job security. Maybe I should write Fortran and get a cushy job.