"You lot aren't programmers. You're just coders."
Paul Coletti in the Advice and Opinion section of CIO starts out this article with the quote: "You lot aren't programmers. You're just coders."
The title of the article is "The End of Bloatware: the Return of Programming's Golden Age?" and it is subtitled, "We've been spoiled by years of abundant RAM. But events could conspire to bring back a healthy respect for lean code."
I've been talking a lot with people over the past month or so about software quality -- what it means, what it doesn't mean; what it is and what it isn't. This article hit home. It's a significant piece of the puzzle.
- If you're designing software, you should read this.
- If you're writing code, you should read this.
- If you rely on people who do either of the above to earn a living, you should read this.
- If you purchase software to use as a part of earning a living, you should read this.
- If you use software for fun or pleasure, you should read this
The End of Bloatware: the Return of Programming's Golden Age?
Really. Read it.
- threew's blog
- Login to post comments
Comments
This is great. It's not so
This is great. It's not so much about programmers or coders, but about what we want from the software - and what we won't tolerate.
Saving bits and hertz through meticulous programming in low-level languages is very expensive and does not benefit anybody (other than the geeks enjoying the process), given the generous hardware support available for most applications today. But the opposite approach to build everything and a kitchen sink into every application is both wasteful and reduces quality. The multitude of features that are not used also benefit nobody but the marketing guy who made those features up. Quality includes knowing where to stop.
The sweet spot is somewhere in the middle. Use the high-level library, skip the kitchen sink.
Thank you for the pointer.
Jane Prusakova
Software Architect & Developer
My blog
Jane, Glad you found the
Jane,
Glad you found the article interesting.
I love your comment, "Quality includes knowing when to stop."
William W. (Woody) Williams
Project Management Consultant
| Blog | Twitter |
w3src Consulting
Well done article. He's
Well done article. He's right - slowly, people have been getting more uptight with bloatware that gobble up resources and extend boot-up time. iTunes should not be that huge.
Coming from the 8-bit Commodore 64 days, I am continually amazed what functionality we could fit in 64K. In fact, programs were often less than 64K unless the ROM and BASIC Interpreter were turned off. Consider GEOS, the graphical OS? Under 64K. Not megabytes...I'm talking kilobytes. When squeezed into a corner, the engineers/programmers delivered. When not squeezed...you have iTunes @ 80 MB.
The article is very
The article is very interesting, and I agree with most of the points addressed. I, too, remember the "good old days" - ironically after a long formal education in PL/1 as well - implementing a self-modifying assembly-code based tool in 256K words to effectively simulate a quad-cpu mainframe, then porting the same to the 640K byte PC memory space. I definitely wouldn't want to do the same now, although such an exercise might be useful for newly educated software engineers. More to the point, though, the significant cost today is development & implementation time, where the use of often bloated 3rd party libraries enables much quicker, and usually more robust, final implementations. Today's availability of processing, memory, and storage resources enable a more effective engineering & development cycle, albeit at the cost of efficient resource usage. However, the choice of language and implementation methodology should be considered within the context of the project under development so that the trade-off between development and resource usage are well understood and properly addressed.
The take-away I have from
The take-away I have from the article is a bit different than a siren song for return to the "good old days" of programming. In fact, I don't think the article is about programmers at all, it's about users... customers.
It started off with people within the geek community grumbling about boot-up times. But at some point in the past few years, nontechnical users -- the vast majority of the world's computer owners -- started to notice too, and what was an imperceptible malaise among us techies at some point morphed into general dissatisfaction within the civilian population.
It's about meeting people's needs better.
People want to spend $600 on a laptop -- they expect it to work and increasingly, will not stand for software that fulfills the programmer's desire to show off instead of meeting their requirements.
The big corporations need to respond faster. It doesn't matter if your software is an all-singing, all-dancing cure for the world's ills; customers now know that anything that comes on more than one DVD or takes more than 50 seconds to download is not necessarily going to be healthy for their systems.
The "bloat" discussed is packing useless features into an already bloated product.
The author is making the point that it's time to focus on things that work (quickly and efficiently) and stick to the core of usefulness.
I say, Amen!
William W. (Woody) Williams
Project Management Consultant
| Blog | Twitter |
w3src Consulting
I agree with your last
I agree with your last comment, Woody, that "it's time to focus on things that work (quickly and efficiently) and stick to the core of usefulness" – amen! Development to "necessary & sufficient" requirements should, and actually "must", be the primary development objective and outweigh the implementation of useless feature bloat.
Unfortunately, many project managers seem to succumb to sponsor/customer requests to include any number of features without properly advising of the impact to the performance & efficiency of the deliverables. While the PM is responsible to ensure the requested features are implemented, he/she also has a responsibility to ensure that the sponsor/customer are aware of the impact of requested features, as well as ensuring that the deliverables conform to business objectives. The resulting bloat is usually a result of insufficient scope management, as well as lack of risk analysis by the subject matter experts concerning the performance/efficiency evaluation of requested features.
Like you said – “Quality includes knowing when to stop”.
The problem with
The problem with sponsor/customer requests for lots of features is that software used to compete on the list of features, as opposed to actual usability, at least at the sale point. The slowness and huge footprint had to become painful before users started complaining that Windows take long minutes to boot, and 80MB-heavy iTunes takes a long while to download and install. Sponsors/POs are just starting to take notice, but it is a shift in the right direction.
P.S.
I said “Quality includes knowing when to stop”, Woody just commented on it.
Jane Prusakova
Software Architect & Developer
My blog
I stand corrected on the
I stand corrected on the attribution, and agree with you that the deliverable should [intelligently] target the "sweet spot" somewhere in the middle.
Tim Ehrler, PMP
Gonna give away my age
Gonna give away my age here...
This article comes about 19 years too late for IBM's venture into graphical UI software. That was IBM's first, large software project. Called "OfficeVision", it was based on IBM's wanna-be-killer OS/2. IBM built the cutting edge Southlake campus, between Dallas and Fort Worth, specifically for this software program, and envisioned 5K-10K folks eventually populating it. Marriott even built an on-campus hotel.
IBM over-imagined and then over-managed the whole program. A couple of middle managers told me over drinks that IBM sent increasingly senior *hardware* managers to salvage the program. (If all you have is a hammer, everything looks like a nail.) The new managers would ask the developers, "Can you make it do this? What about that?" Heady with the attention, the programmers responded "Sure! And we can do something else, too!" As pressure mounted, the programmers were deemed too busy to be able to respond to questions from us mortals, further losing touch with reality.
You can visualize what happened next, but the reality was even worse.
The formerly simple office apps bloated to four or five times the original estimate before the program was killed. (Bear in mind this was the age of 3.5-inch disks, meaning a LOT of disks.) The program collapsed so quickly that IBM experienced its first-ever money-losing quarter in 1990, followed by its second-ever money-losing quarter. Several formerly comfortable IBM senior managers, including at least one corporate VP at the end, lost their careers over the debacle. The Southlake campus never did fill up as expected; as of a few years ago, I heard there were a "couple hundred" niche support folks there. The Marriott became a white elephant, although it's apparently still there. As for me, I really did develop online help and tutorials for mail and filing software apps that I NEVER saw in operation. And OS/2 was never heard from again.
Haven't thought of that war story for quite a while, thanks for listening virtually.
Wayne C. Vermillion
Instructional Designer/Project Manager