I am recently involved in a project which involves reengineering a system which has out grown over more than 7 years.
I was having a tough time just comprehending such a task as most of the requirement was coming as “design” use cases of previous implementation. So here is what i referred to: Big write by Chad Fowler: Here is a reproduction of his work for reference:
"Make it do what it already does." That’s a tempting and simple way to view software requirements on a rewrite project. After all, the system already exists. The question of "what should it do when…" can presumably always be answered with: "what it already does".
There are two major problems with this assumption.
- The first, and most disruptive, is that the programmers don’t know what questions to ask.
- With the fragile safety net of an existing implementation, programmers can easily oversimplify the interface, and assume they know the capabilities of the system.
Solution:
- If there is a software that is complex enough that it needs to be rewritten, it’s probably also so complex that it’s not discoverable in this way.
- This means that domain experts are going to have to be heavily involved.
- It means that requirements are going to need to be communicated in much the same way they are on a green-field project.
- And it means that, unless it’s only used as a supplement, the existing system is more a liability to the rewrite than an asset.
- It means that requirements are going to need to be communicated in much the same way they are on a green-field project.
- This means that domain experts are going to have to be heavily involved.
Optimistic programmers might think I’ve missed something important here. If you’re rewriting a system, you’ve already got the code. The code can serve as the spec, right? Probably not.
I will also like to quote another excellent book “The Mythical Man-Month” by Fred Brooks which states the “Second System Effect”, i am particularly wary about.
The second system that an architect designs is the most dangerous system he will ever design since he will tend to incorporate all of the additions he originated but did not add (due to the inherent time constraints) to the first system. Thus, when embarking upon a second system, an engineer should be mindful that he is susceptible to over-engineering it.
By the way the “The Mythical Man Month” also provides an estimation insight as in Brooks’s law [adding manpower to a late software project makes it later]
- Group Intercommunication Formula: n(n − 1) / 2
- Example: 50 developers give 50 · (50 – 1) / 2 = 1225 channels of communication.
i got into reading into Chad Fowler when i found “The Passionate Programmer: Creating a Remarkable Career in Software Development”
That was when i realized that i was NOT enjoying my work as architect[as it was abstract with NO coding] and wanted to know what lies for people like me; specially in India. [Ironically, The first edition of the book was released as My Job Went to India: 52 Ways To Save Your Job ]. Anyway, I was immediately hooked to the book.
He says “The important thing to realize is that change is not only possible in your career but necessary. As a software developer, you would never want to pour yourself into developing something your client doesn’t want. Agile methodologies help prevent you from doing so. The same is true of your career. Set big goals, but make constant corrections along the way. Learn from the experience, and change the goals as you go.”
I chose AGILE. I choose to change and go for an organization which has ample of opportunities for coder in me over a “well-defined architect role” . And here i am spreading the word of AGILE following “Better Than Yesterday” methodology. I wish everyone could read Fred instead. After all, i am doing the right thing!! 
