|
The most frustrating part of maintenance for me is when the powers-that-be insist on forcing feature after feature into a product that simply wasn't architected for it. A good example is an OS/2 device driver (don't ask) I wrote about 5 years ago. I'm still maintaining the ugly bugger. Its first release was around 8,000 lines of assembly language. It's now at ~18,000 lines. It includes three major custom features (each of which is mutually exclusive to the other) and dozens of minor ones. It adapts to four different versions of hardware.
For the last couple of years, I've developed a litany when the feature zombies (also known as Marketing) shamble into my cube: "Adding-this-will-destabilize-the-product-and-cause-us-more-support-calls-now-what-do-you-want?"
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote:
The most frustrating part of maintenance for me is when the powers-that-be insist on forcing feature after feature into a product that simply wasn't architected for it.
This happened to me once (note once!). I wrote the PC side of a video surveillance over phone line system, for up to 16 cameras using a single phone line. I was then asked to expand the product to support up to four different incoming lines in any combination (PSTN, ISDN, leased, RS-232). I tried explaining to the higher-ups that since the product didn't have this requirement in its original spec/design, it would basically be a rewrite. They were none too pleased.
And neither was I, frankly. This was my first real OO app, and I was under the assumption that what they said about OO, being flexible, having reusable components, all that inheritence stuff, would mean my application would be extensible. Plus, this was a DOS product, how difficult can it get?
Well, it wasn't, because a language doesn't provide for flexibility. You need the right kind of framework, regardless of whether the language is OO or assembly. And it requires a designer that understands how to properly abstract what are otherwise hard physical constructs that are hard wired into the code.
Well, I became that designer after this rude awakening, and the framework I now use is my AAL. (you have seen the articles, right??? ) I've usually have long term relationships with my clients, and THEY have some very interesting clients, so major feature creep is something that I have to ensure is supported by my applications. And I mean, MAJOR. What's interesting is that most of the enhancements I've had to make affect the GUI, the database model, and the scripts that feed the GUI-database and the database-application code. Very little application code changes have been necessary, and some general framework/library enhancements along the way. In fact, one application (boat yard management system) is entirely written in scripts. There's not a single application specific line of C++ code. Very easy to maintain and add features to.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
The old saying:
Live and learn.
Don't and die.
Software Zen: delete this;
|
|
|
|
|
I'm not even doing them myself. The problem is to get this information from our people.
Most of the requirement are very poor, and the give us something that is more part of the design (a few screen shots) than proper requirements.
And the planning is hard to get as well. The keep adding and changing stuff without really thinking about any change in theplanning. But I guess there's nothing new here.
Elrond
Don't be dismayed at goodbyes. A farewell is necessary before you can meet again. And meeting again, after moments or lifetimes is certain for thoes who are friends."
Richard Bach, Illusions
|
|
|
|
|
When a new system is going to be developed, the people to whom it is intended (and sometimes are the people that don´t even know how to turn the computer on) don´t bother to think of what they really need, so we have to investigate and figure out how the system could help them. But then, when the system is ready for testing, there comes that old "it is not quite what I had in mind..."
|
|
|
|
|
How can anyone find development more stressful than design, testing, marketing, deployment etc etc?
Maybe they're in the wrong job...
|
|
|
|
|
During development, all my promises and estimates are put under the spotlight. And all my client's promises and estimates too. Design never manages to unearth all the nasty stuff, because after all, everyone has been ignoring it (the nasties) for years, why start now? And I can talk till I'm blue about up front design, but clients want product, not hand waving. Development usually brings out all the screw ups. Very stressful. But not as stressful as maintenance, for me at least.
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator. Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus Every line of code is a liability - Taka Muraoka Microsoft deliberately adds arbitrary layers of complexity to make it difficult to deliver Windows features on non-Windows platforms--Microsoft's "Halloween files"
|
|
|
|
|
Does not make sense to me either. Development brings all problems to the surface, but problem solving and challenge is what the programming is all about, isn't it?
|
|
|
|
|
As Marc said development is when all the real problems occur, you realize that there are gaps in your design, you can plan for everything and still face problems when you develop, it's not that i don't like solving problems but when you are running on a tight schedule it does create a lot of stress when you get stuck
So yes development is the most stressful part for me although not the one i like the least.
I always think that the idea of a compiler that compiles another compiler or itself is rather incestuous in a binary way. - Colin Davies
My .Net Blog
|
|
|
|
|
The 'last' bug. It is usually not too bad but you are so stressed about doing enough regression testing etc
Davy
Blog for Software Testing, Bugs, Quality, Security and Stability - www.latedecember.com
News From Scotland - The Angus Blog and The Dundee Blog
My Personal Blog - Homepage.
|
|
|
|
|
Is that to say that you always get all the bugs out????
Regards,
Brian Dela
|
|
|
|
|
Sorry, there is no such thing as the last bug...there is only the last bug you have found.
Gary Kirkham
A working Program is one that has only unobserved bugs
I thought I wanted a career, turns out I just wanted paychecks
|
|
|
|
|
|