They are:
- - Re-writes never work.
- - Fast, Easy, Quick. Pick 2.
These phrases are used more to support a preexisting position of the programming staff than reflecting any real truth. They are tools of propaganda and mis-information that are pulled out once in a while to guide decisions to a pre-determined goal.
While experience may have proved these statements to be to true, they must be looked at in context and the amount to sampling to achieve these so called truths.
For those only having 5-10 years of programming experience behind them, the occurrences of major re-writes and FEQ (Fast, Easy, Quick) decisions may be limited. Re-writes of a major product are not that frequent or a product would never get released and provide the business with time to recoup it's investment. Likewise with the repercussions of FEQ decisions where monitory repercussions go up with the increased pressure to cut one or more of the FEQ triads when getting a product to release. For the most part these phrases do appear to hold up as truths. Re-writes do have a large share of issues and FEQ does result in giving up something in the product.
But given enough time, 20-30+ years, there will be times where you can observe conditions where these statements are just wrong, but the conditions have to be right. Lets take a look at these conditions.
Re-writes never work:
Re-writes are required for a number of reasons. The new engineers don't (or won't) understand the existing code, so they want to re-write it. Times have changes and it's time to switch to a new language. The existing code base will not support new features and/or a new architecture is required. The project has failed and we need to get something done and released. It's this last case where re-write failures are high, when the prior revision also failed or was flawed in some way. And it's this context where the statement of "Re-writes never work" is most often used.
What ever the reason, the basic context of the re-write needs to be different. You can not expect the same staff, management and culture to product much different results, something needs to have changed.
I example of this is A Palm Postmortem. Where same staff, same result except for a small context shifting group that produced the WebOS. I did not even know about the failed OS between Palm OS6 and WebOS!
Re-writes require different thinking, understanding and knowledge and far too often staff overstate there ability to change or understate their expertise in the engineering required for the re-write. It's easy to fall back on what you know and the same behavior. Sure, I'm an expert in X & Y! Humm, maybe not.
This is where the engineers should re-evaluate themselves for what is in their thinking, behavior and desires that helped enable the failure of the previous version of the product. Tool, language and design choices based on their personal goals rather than the projects needs? Where their goals the same as the products?
It's tough to admit that personal flaws and feelings effects professional responsibilities but they do. How much they do can decide between the success or failure of a project.
Re-writing a failed project requires new thinking at the least and maybe new staff or management or both.
Fast, Easy, Quick. Pick 2:
For the most part, I agree with this statement. You can not have everything in the project all of the time. There are always constraints and something has to give. Trying to force all points of the triad to be 100% does not work and will only led to stress, conflicts and hidden failures on one or more points.
However, there are cases where you can get real close to fulfilling all points. No software engineer can be be an expert in all domain areas that a project may require. We can be an expert in a couple (at most) of areas but then generalist in many others. The problems arise when it's not really known whom is an expert in a specific domain vs others that are more vocal, visible or in some other way viewed as an expert. the resulting mix of personnel that are placed on the project development may very well suffice for it's development but still under the pressure of FEQ.
But, when the right expert personnel (in knowledge and management) are staffed for a specific project then the FEQ goals can easily be achieved. It's rare, I've seen it twice in my 30+ year career and when it happens, its magic. It's does not matter what project management process is in pace as this mix of staff and knowledge will far exceed any productivity difference processes can provide. It's the people and their understanding of themselves that provide the boost to the project. Communication goes up, the goals are all in the same direction and all FEQ triad areas are kept in scope.
It does not last forever. Projects end, staff move around, life continues and everything changes. When this happens all things are possible, but then again, I've only seen this happen twice in 30+ years.
Comments
Post a Comment