Very little software is written once, installed, and then never changed over the course of its lifetime. And yet, the most prevalent development practices used in the industry treat change as an afterthought. This chapter will teach you to not only anticipate change in your software but develop specifically with change in mind. Also, this chapter provides a set of guidelines and formulas to think about when preparing large product teams for the large meetings that move their work forward.
How to Achieve Sustainable Software Development
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Don’t use C++..
Just kidding. But only slightly.
Edited 2006-01-29 21:19
Don’t use C++..
Should be: Don’t use C++ unless you actually know what you are doing. Then you’ll be just fine. Stick to Java/C#/Python/Ruby/<insert_latest_fad_here> otherwise – especially if performance is not an issue.
Not kidding at all.
What about RTOSes in almost all embedded systems ? I can’t imagine if car break control program crashed during the driving or you’d need to reset mp3 player.
But they’re much less unpredictable than PC software+hardware mix ….
I know that R&R time is directly proportional to how much productive work an employee can do. Most managers seem to disregard this when they fall behind. I once worked at a company that had a company outing with conferences, dinners and all sorts of fun activities lasting a whole weekend. One project was behind and the manager of that project made the entire team stay at work during that weekend. Guess what? The project went under and the company got bought out.
How does the analogy go? If your software has a problem, it’s like a treasure hunter digging 20 feet to the left of it. Instead of widening the search (hence finding the real problem), they just get more people to dig in the same location. In the software business, they just throw more money at it.
We should be thinking about it as more and more managers knowingly put their organisations on the path of crisis management by doing half baked/headline grabbing cost cutting instead of real efficiency investment, which is difficult, long term and hard to sell.
Software is no different, just that the pressure to achieve double digit growth and returns obviously doesn’t very much favour a “doing things right” attitude. And calling staff derogatory terms like “resources” or “head count” doesn’t help getting the most of everyone’s contribution.
Apple is a striking example of what can be achieved by looking ahead. Intel transition planned 5 years ahead, abilility to build video in the iPod whilst simultaneously releasing videos in their shop…. Of course that doesn’t guarantee success but it can help.
Edited 2006-01-30 12:57
Regarding parking lot management, which is mentioned in this piece, I wonder just how much productivity will be lost in the long run as a result of short- sightedness.
Focusing on quarterly earnings and immediate stock prices may have some merit but my guess is it burns employees out and furthermore results in inferor products, especially in the software industry.
But as the educated worker pool is growing rapidly at global scale burning programmers and low level managers out may not be that costly to employers.
I wish real innovation and robust technology would be more prevalent than hyped semi-garbage and P/E ratios.