Software that's built to last
An article on the Windows Vista release tells the story of how Microsoft realized (belatedly) that their development practices no longer supported the release of their software. Microsoft lost a tremendous amount of time because their software wasn't flexible enough to handle the changes they wanted to put into it.Take a look at the applications you use on a daily basis. When was "1.0" of your internet browser released, your email program, the instant messenger program, your music player. In many cases, it's only been around 4-5 years. "Windows", even the NT codebase, has been around since 1992. LabVIEW was first released in 1986. How in the world do you write code that still runs twenty years later?
Most software products change by the addition of features. We add new capabilities that customers are willing to pay money for. The ease of adding those features is directly related to the architecture of the code. A "good" architecture makes adding features easy, a "bad" architecture makes adding features hard. Unfortunately, it's not really that easy. When NI started writing LabVIEW, "networks" were in their infancy (remember ARCNET and token ring? NI actually used GPIB cables to send data between machines at one point). Who knew that one day we'd be doing data servers, remote panels, and web browsers integrated in to LabVIEW? Feature needs change over time. Unfortunately, architecture is much harder to change and it requires real work, it doesn't just happen on its own.
So, have you ever bought software with the bullet point "rearchitected for better developer maintanability!" I don't recall that one making it on "LabVIEW Key Benefits" list. Our customers don't pay for it directly and your customers don't buy your software because you made improvements. But, if you want your software to last, you need to invest in architecture changes. Features pay the bills this year, architecture pays the bills next year. Learn how to refactor, or else you will end up with a rewrite.
posted by Joel @ 12:26 PM
4 Comments:
Amen, Brother!!!
It needs ample courage to rewrite the whole thing. Or simply make enough reasons to decide them rewriting and, if necessary, do resign.
Joel,
Do you know if the LV8's Shared variable is based on a "refactored" LOGOS or a completely new "re-designed" Comm interface? Do you know where i can find more specifics about this underlying framework?
I'm checking on that right now. I do know that the PSP engine (the engine the shared variable is built upon) is designed to take the ease of use of DataSocket but throw away the implementation. I believe it takes some technology from Logos to do it. There will be an appnote forthcoming on it written by someone much more knowledgeable on it than me...
Post a Comment
<< Home