Problems with software development
Yet another thought on what is wrong with software development. The inherent difficulties in software project management have been thrashed over many a times. Also, developement methodologies have been vilified incessantly in technology literature. I rather hold a contrarian view.
First, we should celebrate software achievements. In a mere half century, this discipline has achieved true great heights and is the foundation of all hi-tech. Think about this, we have satellites and spaceships which can correct themselves as they travel through the space. NASA Mars toys had fixed hardware structure but software-wise they were truly a piece of beauty. Once the landers were on Mars, depending on the conditions and surroundings, command center at earth uploaded the newer version of software and obtained optimal performance from the hardware. This becomes more important for ships like pioneer which would be reaching their destination in years down the road. By upgrading the software, we could at least make sure that the new strides in technology could be put in use, even long after the launch.
Anyway I digress, the issue at hand is the software development problems. Now that we understand that the scene actually is not so bad, lets see what plagues us.
1. Team structure: More than any other engineering discipline, I find, software requires the power of experience. Its an infinitely malleable science, where one needs to understand at what point one should stop. Yes, the most important aspect is to discover the optimal ground where a solution is rightly engineered. Watchful eyes, looking for the under and specially the over-engineered design, are a pre-requisite for any team. Yet, the fast pace of evolution means that the experience goes obsolete pretty soon too. This is the real challenge. More than anything I feel we need a balanced team structure in terms of experience and raw energy. Have right amount of youth who is uninhibited in terms of exploring new ideas and the weathered minds to restrain the zealots. Still, in my experience most of the teams are ignorantly composed. Either its the strong belief in youth or amalgamation of like minded industry veterans. Few places where this was managed judiciously, I found the most productive teams.
2. Overloading: The abstract nature of software is its one of the most appealing characteristics and the deadliest too. What seems clever in trying to get a lot out of little, by overloading existing modules in terms of definition and usages, is most of the time a bobby trap. Having seen lots of well intentioned overloading going topsy-turvy, its about time we should put "design guidelines" on strong "no-reuse" of existing resources in new set-ups. Once recent one which I observed in one of my esteemed PhD, 10 yr veteran colleague was in overloading a date field. In existing setup it denotes, the end of a relationship but suddenly he has put a new twist on it, and made it work somehow. His rational is, creating something more straightforward would have been "overkill".
3. Of course the usual suspects, which have been covered pretty well by others:
- Ever changing or poorly defined requirements.
- Dumb or premature optimization.
- Bloated or complex design.
- It aint broken!
BTW I have stolen my new mantra from Google's bag.
"Creating simplicity is a complex task."
"Simply" yours:).
First, we should celebrate software achievements. In a mere half century, this discipline has achieved true great heights and is the foundation of all hi-tech. Think about this, we have satellites and spaceships which can correct themselves as they travel through the space. NASA Mars toys had fixed hardware structure but software-wise they were truly a piece of beauty. Once the landers were on Mars, depending on the conditions and surroundings, command center at earth uploaded the newer version of software and obtained optimal performance from the hardware. This becomes more important for ships like pioneer which would be reaching their destination in years down the road. By upgrading the software, we could at least make sure that the new strides in technology could be put in use, even long after the launch.
Anyway I digress, the issue at hand is the software development problems. Now that we understand that the scene actually is not so bad, lets see what plagues us.
1. Team structure: More than any other engineering discipline, I find, software requires the power of experience. Its an infinitely malleable science, where one needs to understand at what point one should stop. Yes, the most important aspect is to discover the optimal ground where a solution is rightly engineered. Watchful eyes, looking for the under and specially the over-engineered design, are a pre-requisite for any team. Yet, the fast pace of evolution means that the experience goes obsolete pretty soon too. This is the real challenge. More than anything I feel we need a balanced team structure in terms of experience and raw energy. Have right amount of youth who is uninhibited in terms of exploring new ideas and the weathered minds to restrain the zealots. Still, in my experience most of the teams are ignorantly composed. Either its the strong belief in youth or amalgamation of like minded industry veterans. Few places where this was managed judiciously, I found the most productive teams.
2. Overloading: The abstract nature of software is its one of the most appealing characteristics and the deadliest too. What seems clever in trying to get a lot out of little, by overloading existing modules in terms of definition and usages, is most of the time a bobby trap. Having seen lots of well intentioned overloading going topsy-turvy, its about time we should put "design guidelines" on strong "no-reuse" of existing resources in new set-ups. Once recent one which I observed in one of my esteemed PhD, 10 yr veteran colleague was in overloading a date field. In existing setup it denotes, the end of a relationship but suddenly he has put a new twist on it, and made it work somehow. His rational is, creating something more straightforward would have been "overkill".
3. Of course the usual suspects, which have been covered pretty well by others:
- Ever changing or poorly defined requirements.
- Dumb or premature optimization.
- Bloated or complex design.
- It aint broken!
BTW I have stolen my new mantra from Google's bag.
"Creating simplicity is a complex task."
"Simply" yours:).
posted by Learn By Mistakes at 12:40 PM
0 Comments:
Post a Comment
<< Home