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?
Simplicity: One function
Simplexity: Many ways of doing one thing
Complexity: One way of doing many things
Complicity: Many functions
I can usually deal with the first until I'm bored, appreciate the freedom of the second, respect the wisdom of the third, and I absolutely abhor the fourth.
It's not fear of breaking that gets people to not use functions. It's the utter disorganization involved. Most products are built so that an illiterate could learn each thing one day and do just that. The problem is that even if you're somewhat intelligent, the big easy books make things impossible to recall. Granted no hacker would pride him/herself on his/her memory, but his/her skill. Thing is you don't even have the ability to record enough to make a picture of what you're learning and to organize it.
Lwave the basics to the beginners.
If you're doing something a bit more complicated, step up to the plate and learn some insights into the software before you go further. The same goes to devers. Don't dumb it down. It turns into crap. You end up making computers think the way humans do and react the way computers do, instead of making them react the way humans do and making them think the way computers shopuld think.
The message on the other side of this sig is false.
My mother is the director of operations at a school for handicap children, that just begs to have a sys admin. They are now even in multiple sites (with two seperate small networks), and would like to have those networked together in some way (right now they use dial-up networking in Windows on a one-by-one basis). They have people that would like to dial in from home, etc, but they just dont have the resources to manage a small-medium sized network.
I used to "run" their network, which is just a simple file sharing network, with no real servers (in my spare time). But they have set up Microsoft mail on their own, and are frustrated that it isn't easier to maintain. They are just not technically oriented people, but find great benifits in using tech.
The real problem is the pay. Most of the people there are there becasue they want to help the less fortunate, and often take pay cuts. There just does not seem to be a great desire to lend ones technical knowledge to them. I help when im home, but since i have moved away, they are just stuck. I have a feeling that it is the same for most non-profits out there as well. you don't make the bucks, so you can't hire the help. People can donate their time, but the people with the proper skills (usually these people are younger), are not willing to help.
Just my observations, and encouragement to get involved in a cause that you think is worthwhile. They could definately use someone that would rather hammer at a keyboard than hammer a nail.
Something similar to this happened at my Highschool. There wasn't a large budget for the tech program at the time so he recruited students to learn and set up the network and computer systems in the district. He got it to the point where students could receive credits for doing it. He taught the 'Tech class' on his own time for no pay. The district ended up driving him away when he asked for some compensation and replaced him with 3 people who knew less and *each* were paid more than what he was asking for.
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.
Ya, its funny how they say that the bugs shouldn't even be there, yet they also say that testing is a waste of time. Its also by that logic a waste of time to test circut boards, cars, or just about anything else you buy. Computer programs are among the most complex things ever designed and 'built' by man. As such, its expected that large and complex things not be 100% by release, and obviously need to be tested. I got halfway through the article before i couldn't read anymore; its too ubsurd, and written by someone with little to no clue.
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
It's certainly true that testing and debugging are part of a programmer's job. But it would be nice if they didn't make up 90% of a programmer's job.
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
- Of the total spent on debugging, 20% goes to killing 80% of the bugs.
- The remaining 20% are really tough bugs, and take 80% of time.
- In a business, 80% of the profits are produced by 20% of the employees.
- 20% of a business's customers create 80% of the problems.
- Writing the program is 20% programming, 80% debugging.
- Your boss gets 80% more pay than you, but does 20% less work.
Just to mention a few. And you can always create more: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."
One big reason software developers can't spend time working on new features is that most programmers won't write code that is easily modifiable unless they know they will have to modify it themselves in the future (and even then a lot don't). Using RAD tools that develop quick and dirty two tier applications with dbtext widgets work great when you develop the application the first time but when the schema or data source changes for the widgets you have to go and modify ALL the widgets in the application to use the new schema instead of modular components that take care of db access for all the widgets. Ending this shortsighted two tier approach and instead creating multi tier robust applications the first time will go a huge way into increasing the productivity of the programmer in the long run where it matters instead of the productivity in the first cut which RAD tools focus on. I'll take a good guess (maybe others can give more insight) in saying this is especially a problem in contract work where basically there is a lot of pressure to meet deadlines and who gives a f*ck how easy the code is to modify after the contract is finished. I think its obvious that more programmers isn't going to solve the problem as you only wind up with graduates who can't even grasp the concept of creating modular multiple tier programs( you know the ones i'm talking about.) The best path is for the skilled programmers to lead by example with good programming practices, taking accountability and pride in your code and teaching others to do so also.
This comment was generated by a Squadron of Ultra Ninjas
OK, 47 days sounds reasonable for actually writing code, but debugging it is work!! I've heard it said that programmers spend 10% of the time writing code and 90% debugging it. That's perhaps too extreme, but some bugs can certainly be hard to swat.
I agree fully. Indeed, when I'm "programming", I'm spending more of the time debugging and cleaning things up than I do when I'm first writing the code. I don't even distinguish between the two when I say what I'm doing. Debugging is such an integral part of getting something working that I consider it all part of the same thing.
When we talk about when a writer is "writing", do we just count the first draft? Take out the time when he presses the "delete" key? Take out the time reading, proofreading, and rewriting? All of that is considered part of writing. Why is debugging not considered part of programming?
-Rob
- 1/3 planning
- 1/6 Coding
- 1/4 unit testing
- 1/4 sytem and integration testing
Most of the time spent developing software is spent planning,designing algorithms and testing , initial coding takes very little time with respect to the other factors. For anyone to claim that debugging and testing are not or should not be major parts of the development process is sheer nonsense.Grabel's Law
It's still work, even if a project gets cancelled, because I spent time on it, and I still got paid for it! My boss has sometimes not implemented a feature because the cost for programmer time would outweigh the benefits.
Now some programmers may only spend 47 days a year working a the rest surfing the web, but I value my job!
"It's better to keep your mouth shut and be thought a fool than to open it and remove all doubt."
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.
I somehow fail to find that surprising.
Every programmer knows that no matter how determined one is, debugging and pieces of "work in progress" (that'll be canned for some reason) are major time spenders.
I assume that study is targeted for management audiences with no technical knowledge so I won't slander it.
I believe it's pretty clear that simpler is the way to go. Compare Linux to the proprietary OS with the largest desktop market share and you'll see the largest example of this.
Furthermore, a "light-weight word-processor that imports foreign formats correctly" is an oxymoron. If your word processor is so light-weight it'll end up discarding most of the features that advanced processors use, so the file importation won't be that correct.
I can safely state that this "faster, lighter, simpler" idea is nothing new at all and has been used for eons by competent programmers. Every simple piece of software that stays simple is an example (look at vi and all basic unix tools).
If you want something newer, I'll mention abiword and xmms.
This revolutionary concept is summarized in one term: focus.
Flavio
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