Wednesday, December 07, 2005
Design for Maintenance
I have always believed that the mind of a b-boy and an enterprise architect were in harmonic balance. Whether it is the neighborhood at work or at home, they have witnessed others let their surroundings fall into an abysmal state where no one really understands the legacy left behind any more. Even worse, future generations have failed to train others such that their neighborhood is sustainable and the knowledge they need to know to look after such important assets.
In suburbia, they can't seem to figure out why poor people remain poor or why some people can't just get a job and chalk it all up to attitude (they are only partially correct). Likewise, within an enterprise, the business as a neighborhood struggles to figure out why it takes "forever" to get a simple change made on these mission-critical systems. Like the all the stores moving out of the neighborhoods and downtowns to glitsy malls, the enterprise too is loosing employees to the evil that resides within the mall known as India. The enterprise is left with nobody that knows how to write COBOL. It would be laughable if it weren't so sad.
Like poor people, developers are the low-status position within the enterprise reminiscent of a caste system. Maybe if the enterprise eliminated all forms of caste systems and the people who still practice it, they would be in a better state. No wonder both neighborhoods and the enterprise are in a state of disrepair. After all, they are being looked after by folks who can't wait to stop doing maintenance and start working on "real" projects.
I am not sure what JT was thinking about when he tagged: Design for Maintenance (and I am sure he will tell me) but in my humble opinion his comments weren't really about architecture (although he may believe otherwise) and are all about the human aspects of technology. Hopefully, he was thinking about the following:
- Planned obsolescence is fundamental to good architecture: Systems and the code one writes are not "things of beauty". They are meant to have a defined start and end date. Enterprise Architects usually focus on the start but never can seem to make things end (except their own careers).
- Dont' kick the homeless (oops developer's) to the curb: Folks want to work and live in nice neighborhoods. Losing an experienced developer who takes pride in building valuable working software is very expensive! Large mission-critical enterprise applications takes years and sometimes decades to learn, so it is wise to retain the people who know the applications.
- Don't treat developers like the stepchild: We all know that the best way to attract and retain good people is to pay them. We understand that many enterprises lost folk during the dot-com era as folk were chasing the hot thing of the day. Make maintenance hot, in fact make it blaze and you will have followers up the bleep.
- Developers, like B-Boys write rhymes not documentation: Folks in the enterprise need to stop playa hatin against those who write code. These G's can't be replaced by documentation. The haters (aka management) sometimes don't acknowledge that software development is a learning process and the folks best equipped to maintain it are the ones who wrote it. Outsourcing requires two teams to learn the application which in of itself isn't good economics
- Kidnap that fool (aka manager): If you hear any manager saying, if it ain't broker, don't fix it, B-Boys should kidnap them. Minimally, they should instead be rhymin: "Maybe it ain't broke, but we can improve it". Maybe instead of kidnapping, you could simply send them to this link on merciless refactoring?
Maybe Enterprise Architects and B-Boys' alike should listen to Chuck D. of Public Enemy and blast: Rebel without a Pause during meetings...
Links to this post: