Slashdot Mirror
Programmers work 47 days per year
According to a new study from the consulting firm
Software Productivity Research, software programmers spend 47 days
a year developing or enhancing software applications. The rest of the
time is spent testing, fixing bugs, and working on projects that will later be cancelled. This might be deemed poetic justice, given that users avoid using more that 10% of application's functionality for fear that something will break. On the other hand this could be seen as good news for newer projects: add fewer features but get them right. Eg: a light-weight word-processor that imports foreign formats correctly, but only has the features most people use. What do you think? Can anyone corroborate the article's statement that 90% of nonprofit organizations in the U.S. cannot afford to maintain more than 15 networked computers?
While it may be true that most Word users use only 10% of the program's features, they don't all use the same 10%. If you were to create a simple word processor that only had 10% of Word's features, which 10% would you pick? The 10% you use?
It's the obscure features that make a product popular and hard to displace. A small fraction of Word's users use Word to create documents with complex mathematical formulas, but those users have to have something like the EQ field or the Equation Editor. Most users have no idea what either of those features are, but most users have some backwoods feature they do depend on to make better looking documents quickly. They will never willingly switch to a product that doesn't have their pet feature.
The same is true of other products. Have you ever looked at a new email client that did some useful things your current client doesn't but lacked some minor feature you're sure you can't live without? Did you willingly switch anyway? Most users won't.
Simply requiring that this simplified word processor does a good job of importing documents requires that it be complex. When you open a document in a product that doesn't support the original application's full feature set, and your document doesn't come through looking just like it did originally, do you say, "Gosh, I guess I shouldn't have used a feature outside of the universal 10%" or do you say "this product and its crappy import filter are useless, give me the real thing even if it is bloated and cumbersome."
Complex cumbersome apps are a big problem, but it's hopelessly naive to think the solution is to just write a new product with fewer features. It doesn't work. Even Microsoft tried that strategy once - Microsoft Write for Macintosh. It was a trimmed down version of Word 3.0 that sold for about half of Word's price. Sounds great, right? But Microsoft couldn't give it away.
If you want to design a new product to replace a high-powered popular product, you need to build something that supports a superset of the feature set and does it in a more elegant, intuitive manner, where "intuitive" means "easily figured out by current users of the big ugly product". Anyone who thinks that's easy to do has never tried. Of course there's a $billion a year waiting for anyone who can do it.
In page 20 it says:
- 1/3 planning
- 1/6 coding
- 1/4 component test and early system test
- 1/4 system test, all components in hands
That yields 1/2 for testing and only 1/6 for programming. If we assume that programmers in small companies and start-ups do at least the three first phases (I guess that the fourth one is for customers Alpha/Beta), that gives us:- Planning: 94 days
- Programming: 47 days
- Component Testing: 70.5 days
Total: 211.5 days/yearGiven that a labourable year has about 45 weeks*5days= 225 days (11 man months), which means, that according to Brooks' distribution of software engineering work, those programmers only spend 0,66 man months a year for coffes, reading, research and so on.
One of the figures lies, or we work more than 11 man months a year or we don't drink coffes at all.
--ricardo
sgis ddo ekil t'nod i
All of this means that when something goes wrong with their 4-computer network, they have to hire in an MCSE at $200/hr to fix it (which he usually can't; I think he knows less about networking than your average gerbil) because there's *no* way they're going to afford (or justify to their BOD) a full-time network technician. Their accountant is studying for her MCSE, but she appears to be learning even less than their current computer rodent knows.
As for buying new computers, forget it! My mother has finally convinced her boss to replace her 486, after she made him sit down and watch how long it took to open Word, *and* got a quote proving it would be cheaper/easier to buy new than to upgrade the 486 into something useful. They barely make payroll most months, they certainly can't increase the size of their network.
oh, and by the way - their board of directors are such technophobes that one of them adds up the financial report every month on his pocket calculator, because he doesn't believe Excel will add numbers right. Good luck convincing them to free up funds for a shiny new network (or even a slightly dinged one), even if there were such funds. I'm donating my old Celeron 266 to them in a few months, just so I don't have to look at the pieces of crap they're using now.
"We can't all, and some of us don't." -- Eeyore
software engineering gurus believe that if the proper techniques are used, the number of bugs can be cut drastically from the current norm
This is a topic we spend a lot of time discussing where I work. There are adamant opinions on both sides of this issue. The question is - What magical techinique are you going to use to eliminate bugs?
Most of the techniques that are commonly used help eliminate crashes, deadlocks, interface problems, etc. But they do NOT insure that a program does what it is supposed to, or that it is intuitive in the eyes of the user.
What good does it do for a program to be stable, if it adds together 2+2, and gets 5? And like the article in this thread pointed out, just because a program is stable doesn't mean the user understands how to use it.
My basic point is that nobody has found the "magic bullet" yet. Even if we use some magical tool to insure that a program will not crash or deadlock, the computational logic and usability are not guaranteed. Only a human being can check those types of things. So in the end, magical techniques are no substitute for just simply being a good programmer (or a well communicating team of programmers).
--- "So THAT's what an invisible barrier looks like!" - Time Bandits
This soons sooo much like the old CISC vs RISC arguments!
Someone needs to develop and outline a RISC UI environment and tools; Reduced Interface Set Computing, or something.
A set of small, fast, reliable, easy to develop, easy to debug, easy to enhance set of tools. The base for this exists in the GNU toolset... but this has to be applied to a bigger base.
A image processor that handles photos, web-prep, and printing, for the average consumer, without continually adding features or cruft that users don't really use. Leave the hooks for plugins, of course, to enhance and extend it... but leave the core simple, small, and reliable.
Winamp is something very similar for songs and sounds!
Mozilla could stand to be something similar. Is there already too much cruft in it? Mozilla-PARED?
Word processors? VI doesn't cut it, as much as I like it. A Wordpad++ or something like that.
Anyone agree?
Geek dating!
GPL Deconstructed
I am a programer, so I know for a fact that this is not right. 47 days is the time reported spent on programming. About 70-80% of that time is wasted on stretching lunch breaks, surfing the web, chatting and other things.
---
This message has been ROT-13 encrypted twice for higher security.
Why is testing and debugging not considered "work". It is perfectly valid and is in fact a major component of any programmers job (and it SHOULD be as well). Programs would be a lot better if there was more testing and debugging. In other industries this is called "refining" and "perfecting".
Ken Olsen, founder of DEC, was once asked how many people worked there.
"About half."
so you're saying (with that title) that programmers aren't *WORKING* when they're testing, debugging, coding projects that end up shitcanned, etc.?
A more proper title for this article:
Programmers Code for projects that eventually see the light of day, 47 days per year.
The other 318 18-hour days, they're working their ass off doing the other stuff.
Do programmers only code? News flash, duh, they don't. gee whiz, I think I'll change my major now that I've learned this startling revelation.
No, actually they spend the other 318 days reading "Visual Basic For Dummies" books.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
To paraphrase a popular photocopied piece: The meetings will continue until we find out why so little programming gets done.
--
A feeling of having made the same mistake before: Deja Foobar
In Austin, Texas, where I live, the technical-support ratio in the local school district is about 2,500 computers per tech-support person. The district's ratio means a majority of its computers get no attention at all. One local high school has computers still sitting in boxes, months after their purchase, because no one available knows how to set them up.
Yeah, because there aren't three dozen geeks at that school that wouldn't rather set up the boxes for free than do super-easy high school assignments. When we got computers at my old school, our physics teacher wanted to actually use his, so he had a couple of us set it up surreptitiously (students weren't allowed to touch them). Before long, there was this underground network of teachers saying "psst, could you guys set this up for me?", and when the official guy came around to finally do it, he poked around, shrugged, and told the teachers everything was great.
--
Communication is only possible between equals