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?
Where I work biggest problem comes from requirements not being solid and changing from day to day. Sometimes without even being informed of these changes. It's a moving target... Luckily I'm not so shabby at sniping...
Other issues include the constant re-organizations and endless meetings. People not taking responsibility for their actions. Idiotic contractors... The list goes on. People are coming and going so fast no one even remembers who or what they did.
Miscommunication across the board. People going around finding out who didn't do what instead of just doing it and getting it out of the way.
It's a mess.
And I don't doubt these things happen elsewhere as well. Time is wasted in misunderstandings rather than planning things out at the beginning and saving everyone the time at the end.
Okay. I *think* I'm done ranting...
WRT the simple vs. complex applications: Isn't that the Unix philosophy? A number of simple, small utilities that work together to perform complex tasks! Edit a file with VI, check it with ispell, convert to the format of your choice with any number of utilities. Given, modern users don't like the command line, but couldn't we create GUI programs that allow the same interoperation?
Jeremy
Hi-Technical Excellent Taste and Flavor!
In practice, I find that the complexities of meeting user requirements adds major challenges to the job. The alternative would be writing hard core mathematical software, which needed raw brainpower to determine efficient algorithms. At least users are friendly, buy you coffee and let you beat them at snooker - and are also someone to moan about when you need to loose off some stress.
The other benefit is that because the users don't even know their own business processes half the time, you can make a discernable impact on the business itself by both making recommendations to them, and also just making decisions on their behalf. I like having that level of influence, and it's a nice side-effect of the job I do.
I guess I could get a job that is just making business decisions, except that writing software is far more fun...
~Cederic
Coding is a minimal part of a design work, such as software development. It is like the time architects spend drawing the plans of their designs.
47 days a year performing the tasks that're in our job description, I can believe. However, I'd bet a big stack o' money (that I don't have) that we spend, and are expected to spend, a lot more time working than most other professionals.
End of lesson. You may press the button.
Not to get into a methodology war, but RUP is iterative at a fundamental level, and perhaps like XP's "user stories", the fundamental requirements building block, if you will, is the "use case".
The point I was making in my earlier post is not so much that modern software methodologies don't have methods of measuring productivity - The ones we've mentioned do. My point is that the culture of software management is often one that is uncomfortable with these metrics. What most software managers (at least the ones I've met) want to see is source code gathering in repositories, not use case diagrams or insert_your_methodology_objects_here.
As for having quick access to users and/or requirements generator folk to help me with requirement clarification/disambiguation, I've found that this only happens under two conditions: :-)
1.) The software you're developing is so overwhelmingly wonderful and necessary to the user that they are dying to help you develop it. (Don't laugh! It's happened to me!
2.) Some upper level manager tells the users/requirement generator people that unless they get completed software by Day X, they should seek other employment. (This has happened as well...)
"The plural of anecdote is not data" -- Bruce Schneier
The reason they are out of date is that a lot of the testing has been taken over by QA departments, at least after Unit Testing.
Wovon man nicht sprechen kann, darueber muss man schweigen. Ludwig Wittgenstein
42 is the answer. 47 is everything else.
----
Celebrate the finer things in life
Part of the problem (perhaps most) is that so many of us are maintaining applications and systems that have hung around since the dark ages. We inherit this junk and spend most of our time trying to get it to do things that was never part of the original concept. Few organizations will authorize the rewrite of a functioning system, even if it's riddled with bugs. Nor will they give us time necessary to 'do the "Raid" thing' and exterminate the bugs.
Another part of the problem is that if we waited around until the users gave us enough info for complete specifications, NOTHING WOULD EVER GET DONE! Sheesh folks, we're SOFTWARE ENGINEERS, we write code that automates what's in the users heads! If the user can't (won't) explain what they do, we can't implement it...
I'd LOVE to be able to wait for complete specs, but if I did, someone else would soon have my job...
Capitalism - a horrible system, but simply better than anything else that's been tried...
At least in my current experience i don't think it's so much coders not planning their code out, it's schedules artificially compressed by mgmt at expense of high-level design, etc., which would prevent a lot of the back-end cost debugging this crap. there's too much pressure to just sit down and start coding.
anthony
Fah, neither management, nor the customer actually have any idea what they want until they see what you have done and then utter the fatal words...
"Well, that's almost right."
At which point the customer is generally able to point out the ways in which your software is wrong. This is perfectly normal. If your customer knew anything about software design, they could write the software themselves. They don't, however, and so they don't categorize the million and one exceptions until your software somehow magically fails to divine them from thin air.
That is actually one of the reason why Open Source hackers "scratching their own itch" are such an effective programming force. They happen to know what they actually want the software to do the first time that they sit down to write it. It's also why planning to "throw the first one out" is such an important concept. Unless you are writing software for yourself you will almost certainly misunderstand the customer the first time (or more likely they will fail to give you enough information to accurately understand the problem).
Planning needs to happen, design needs to happen as well, but feature creep will happen (especially with new projects where the programmers are not expert in the particular field).
. . . or mabye you're writing on a broken API like MFC, and due to project constraints, doing otherwise isn't an option.
Maybe programmers spend the other 318 days a year working around MFC bugs.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
then you might not be spending enough time on solid design and correct coding or even just determing requirements before working
Remember, that most programmers are not the ones that are comming up with the requirements. I dont know how many times we have something planned out at the beginning, start building, then every few days, someone from marketing or biz dev calls and says "oh yeah, we need this too", or "this has to do this now". Every time this happens, you cant throw everything out, redesign, and start over, or you would never finish. So you adapt the old code to fit the new requirements or enhancements. Unfortunately, since you didnt plan for the new reqs, there will be unforseen problems.
The more mature a project, the more bugs there will be.
The ivory tower has never had to reach so h
have fewer than 15 people in the office needing a PC. Just a thought.
sulli
RTFJ.
And yet some of these packages still manage to be quite robust. For example, when was the last time that you crashed your Linux box (not on purpose :)?
I have been using Emacs since 1995, and am constantly amazed by the next weird thing someone has gotten it do. For example, do you know that some freak show wrote a GNUS backend for Slashdot. I can now read /. using both my GNUS scoring system and the /. moderator system. That's insane!
And yet in all the years I have used Emacs I have never had it crash one me. My Journal is a 200 page LaTeX document written primarily in Emacs, and I have written who knows how many lines of code, in several languages. I use Emacs as a debugger, a mail client, a web browser (well, sometimes). I even play the built in games. And yet I have never ever crashed the darn thing.
Of course, Emacs is pretty modular (read, there are a whole pile of Lisp packages). But it certainly goes to show that a program can be big without being a bug haven. Sometimes the next cool thing really is the next cool thing.
A friend of mine who used to work at Apple was in a program where they helped inner city schools set up their networks,etc. I think this was organized by the corporation. Does anyone know of anything similar that I could do to volunteer some of my time to help out in San Francisco schools? You'd think there would be programs like this.
---- Do not go gently into that good night -----
47 just makes a lot of sense. I can't imagine it being any other number.
----
Celebrate the finer things in life
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.
How on Earth can you say that. That was and still is one of the best things invented. If only modern IDEs, such as JBuilder supported VI mode. My productivity would be 2 times higher.
VI still cuts it.. VI lives.. VI is the best.... well.. YEAH!!
http://dtum.livejournal.com
i am a "consultant" but i'd say i spend much more time reseting passwords and and fixing things than i do planning
I believe sex is highly over rated... unless it involves me
bm :)-~
US Democracy:The best person for the job (among These pre-selected choices...)
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.
So if I work 47.5 days a year, I can get a pay raise?
Huzzah!
I got a B in economics in college so maybe my crack habit hasn't affected (too much).
The way I see it, if only 47 days out of 364 put to innovation...thats 11%. Thats assuming all programmers do is drink jolt and are handcuffed to their cubes... oh I was supposed to make something up for that analogy... forget it. 11% of anything sucks. Now keep in mind IANAP(programmer) and I know that it can never be 100%. The only point I'm trying to make is that I think as the IT market matures (20+ years) we'll see this ratio get higher because there will be less standing in progresses way, like the Execu-droid 2000 that listens to the consultants instead of you and asks to bring in your own copy of a visual C compiler. Also, IANAE(economist)
"Me Ted"
BOSTON SUCKS!
To understand what's right and wrong, the lawyers work in shifts ...
There is no magic bullet to take the place of innate talent and competence (pride in workmanship, follow-through, caring, etc.). I would like to coin a phrase: "It's the programmer, stupid!".
Extra "quality processes" can significantly improve quality, or they can get in the way of it... depends upon how the process is designed and implemented in reality. Even with immense software development experience, it's still a very difficult exercise to review somebody else's code and do a good job at revealing all or most of the problems therein.
Steve Magruder
Steve Magruder, Metro Foodist
Technically, only private Universities, and only some of them, are non-profit. There are for-profit Universities. Also, State-Funded Universities are not non-profit organizations, they are publically-funded (e.g. they are a part of the state government and therefore don't fall into the non-profit category)
(j/k)
(o/t)
Hmm, it's a while since we've seen Sengan round here... he got booted, didn't he? (Can anybody remember what for? Something to do with Iraq if I recall?)
Anyway, welcome back!
Cheers,
Alastair
-- "I believe the human being and the fish can coexist peacefully." - George W. Bush, 29 September 2000
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.
Oh my, check out the moderation on that post: funny, informative, underrated, redundant, troll. Looks like moderators are having turkey hang-overs today.
"Hot lesbian witches! It's fucking genius!"
I know a certain non-profit organization that maintains helluva lot networked computers... :)
-jfedor
My father worked for Bonneville Power Admin.
for 9 years in the Long Term Study program.
He had models of stream flow with over 100 years
of data. All in the form of multi-hunred-MB's
excel spreadsheets. He said the margin for error
was a less than a 1/100th of a percent. For the most
part, excel sucks only as bad as the operator!
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
But about making and selling applications with simpler, smaller feature sets, I think you're going to come up against two kinds of reality.
-Daniel
I don't charge by the hour that is my retainer if my stuff broke and it took me 20 hours to fix it I would get $200 for that month. I'm good but not that good but I do have the good sense to choose good tools. This is why I can make $200 on retainer and barly work. OSS rules for this reason.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
And I mentioned this book because it was referenced in the survey. It also mentioned Brooks' (his surname is "Brooks", not Brook, read the cover page, not only page 19 :-) was given the Touring award, so he _should_ be right.
So, take it easy guy, we all know youve read the book. Indeed, although I am not Williams Shakespeare (Cervantes neither), I can read (and write a little) of English.
--ricardo
sgis ddo ekil t'nod i
On the other hand, I wouldn't mind volunteering my time to work on a NP's network. Of course, it has to be a Mac network. Or a Linux network. Either so easy to set up, you can show someone else, or so bullet-proof, you set it up once and forget about it (Set it and forget it, Ron!). Windows networks are designed to keep sub-par network admins employed.
Do not touch -Willie
...and on the 48th they rested.
-Shawn "If the Name Don't Rhyme It Ain't Mine" Conn
I totally agree with that.. management does put on pressure to get products out the door, which in turn is pressured by marketing.. or lack thereof.. IMHO it tends to always be a case of not clear communication between pertinant(sp?) parties which leads to the ultimate demise of a lot of products.
This is so sad and predictable. Anyone else see the cause and effect?
"Keep the MSCEs away, any maybe mom will have some decent software instead of MS Word, and the 486 won't seem so bad," types Sloppy on a 50 MHz 68060 that is a hundred times faster than what is needed to keep up with his fingers.
You think things are bad now? Wait until that accountant finishes her indoctrination.
When a machine as powerful as a 486 is too slow for word processing, it's a pretty good sign that someone got conned. Funny how MSCEs always end up "upgrading" everything and then when things become slower and less reliable, the users are even more dependant on them, giving them more power, so they can fuck up the computers even worse. What a racket! Even crack dealers don't have it that good.
Joe Schmoe and your mom can manage computers. They just need to learn a few things. The things they need to learn aren't computer skills. What they need to learn is to be skeptical, when to say No, and when everyone they know jumps off a cliff, they need to realize they don't have to jump off a cliff too.
Technophobe? Sounds like an Excelphobe.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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 this post we see the statement "users avoid using more that 10% of application's functionality for fear that something will break." What percentage of users say they only use 10% of the app's functionality? Maybe they use 10%of the app because that is all they need 90% of the time. What about the other 10%. What about when you need to insert some kind of questionalble scripting into a document, or if you actually need to look at the behing the sceens "code" that makes RTF look the way it does, or insert an image/auto generated spread sheet? And, I hate to ask this and posibly seem like an anti-MS freek, what percentage are useing Microsoft apps. I know I would hate to have to buy 5 word processors just to get all of the features. Maybe installing functionality as needed would be a better idea. A word processor with RT support, tha does tables, indensions, and images, and vector clip art as the default load with addons(included of course) for all the rest of that crap. Maybe even a load as needed or when requested senario would be preferable. Or am I a jack ass?
my last year of college my network class went down to the local redcross office and set up a network with shared dial-up and a file server. they got what they needed and we got experience and something to put on a resume.
there will always be someone out there looking for experience so non-profit's should target them and get as much help as possible. it can work, i've seen it, at the school MY mom works at and at several redcross locations.
the downside is that occasionally you get bad advice. i've seen places buy expensive hardware on nonknowledgeable advice and networks get screwed, but the benefits outway the occasional problem, especially if you have no help at all.
you're all figments of my deranged imagination
especially if they're moron users who install the latest "Elf Bowling" apps and play them all the time, run every javascript module they can find on the web while playing shit like iwin.com, yada yada... i've generally found that it's the 'i don't know anything about computers' people that put all the stupidest shit on them, install everything in sight, and in general flush the system straight down the toilet as quickly as possible. maybe this is just too many years of tech support or something (tell hawk@xer0.net that i plugged techcomedy.com for him, heh) but IMO lusers trash their comps harder, faster than geeks. i could be wrong. *shrug*
eudas
Blessed is he who expects the worst, for he shall not be disappointed.
...that life is like a Dilbert strip.
Kierthos
Mr. Hu is not a ninja.
The "magic bullet" for those issues is requirements analysis and requirements, design, and code reviews. Requirements that are supported by test cases, peer-reviewed code, and configuration management by technical experts would go a long way towards making sure that the right code is being written. This sort of falls under the communication that you mentioned, though.
One possible exception: when the user decides they want things to work in a different way after you've already written the software once. That's more of a feature creep problem than a real bug, though, and it's basically management/business people's jobs to deal with that sort of thing.
Your right to not believe: Americans United for Separation of Church and
As IT administrator for all nonprofit organizations in the U.S., yes I can.
It sucks when that happens. But that's a management failing, not an engineering one. Management is supposed to shield the technical guys from feature creep by expressing to the marketing/business guys exactly what the cost associated with their change will be, and sticking to it. And it never hurts to multiply all time periods by two and convert to the next highest unit, either :)
The best situation is when the engineering team owns their product/feature requirements, and others have to talk them into adding features rather than imposing those changes on them from above.
Your right to not believe: Americans United for Separation of Church and
47 Hours per week, plus another 20 reading tech journals and books, 20 more reading/research online, 10 more hours per week mulling over problems in the back of your mind. 100 hours per week seems right. Philip K. Dick inspired grindcore:
Get my free Hitchhiker's Guide Tribute Novella:
No wonder it takes so long to develop software. The people who do the typing are only at work 1/7 of the year..
Hmm...only 47 days? that means I could be a programming during winter break.
(I could keep going, but this has gotten old..)
All microsoft bashing aside-
Would MS Word be more more valuable if MS decided to 'Freeze' the feature set of Word? (only changes made would be bug fixes) This would attract much more development and a quicker adoption of Word as a standard. People would also have more incentive to take classes to learn Word.
Maybe open-source could take the leadership role with this idea.
love is just extroverted narcissism
Get rid of bloat?
Then what would happen to:
Kde, Gnome, Enlightenment, Bash, Eterm, RedHat, and Suse? I guess everyone would run blackbox, aterm, ksh, and play xevil on OpenBSD all day.....
I doubt dropping bloat would help projects complete faster...it would just give us more time to look for sparc stuff on ebay and play xevil.
Chaos, Mayhem, and Destruction: Not
This is kind of a muddled analysis. If you work a lot on projects that get cancelled, then this is a problem with your management. If you spend time dealing with poorly written vendor products, as illustrated in the anecdote at the beginning, then this is a problem with the vendor. If you spend a lot of time debugging, then, well, that's programming for you. As for testing, are they saying people should test less? Then we'll have more of the second problem, except you'll be the incompetant vendor to someone else.
I'm not exactly sure what this article is about. Bad software? Bad management? That programming is hard? You can't really address a problem if you don't know what it is.
90% of nonprofit organizations in the U.S. cannot afford to maintain more than 15 networked computers?
That's probably true. If you think about the amount of nonprofits in the U.S. and their average sizes, you will realize that most will never have use for 15 computers at once.
Case in point: I help out once a week at a synagogue in my home town. One of the two largest in our area (the admittedly small city of Cincinnati), they have maybe 1000 families -- ranking them in the upper percentiles of all nonprofits in terms of size. They have 6 computers networked for the religious school, and in the office they have maybe 15. I don't know about the ones in the office, but the school computers are really old Cyrixes. They at the moment do not have any use for additional computers.
My point is that even a very large npo doesn't need that many computers. Take a count of one computer per employee, plus 1 misc per 20 employees, and consider that the average npo has a very few amount of employees.
Remember: Even the Klingon Language Institute is a nonprofit organization. While the larger institutions may dominate the headlines, there are more than enough very small nonprofits to make the 90% figure quite reasonable.
Okay, but let's say that my 10% and your 10% differ by .5%. And another user's 10% differs by .5% as well. Given most programs, after a relatively small user base, that will not happen any more. In the case of a word-processor program, most of the users use the same features over and over again because they don't need to use anything else.
The only reason some of the features are included are to give people more options and as selling points. Half the functions on the copy of Word 2000 I have I never use, and I never plan to. Again, the vast majority of users are probably the same way. It's not that they don't necessarily know how to use those features. It's that they don't need to. Change font and font size, bond and underline are probably the most commonly used aspects of the program other then print.
Be happy that those features are (mostly) bug free....
Just my 2 shekels.
Kierthos
Mr. Hu is not a ninja.
I agree completely that small and simple applications are the way to go. This is the one thing that Microsoft continually gets wrong (my DevStudio folder is something l42 megabytes alone, even after deleting all the help files). Unfortunately, the open source Linux crowd is following Microsoft in this regard, with hugely bloated applications and desktop environments. You've got to give Linus credit in that he tries hard to keep cruft ouf the kernel. He's one of the few.
What's odd is that when people think "small," they equate that with "minimalist and unusable." But really, that's not how it has to be at all. They key is just keep focused on the problem at hand, and not adding crazy tangential features that are outside of your domain (like email, so the old joke goes). I get the feeling that many developers for, say, KDE (not to pick on it specifically), are more concerned about adding impressive features than they are about usability. And that, sadly, is the same mistake that most big software developers have been making for years.
I can only speak for myself, but I have worked for two non-profs, Wash U. and a home for mentally retarded adults. Needless to say Wash U. had exponentially larger netorks than 15, and the MR home had about 50 when I left.
I would guess non-prof or not has little to do with it. I think it is size that matters, (as always).
- I like pudding.
This is one of the major problems with Microsoft's products especially their Office line. I think it was Excel 97 that included a "3D" flying game that made excel bulky as hell. I have probably never used more than 97% of Word's features, all I need is a basic text editor. Now why doesn't anyone ever seem to do this?
Very good point. By that argument, quality control people, and business consultants don't work at all
;)
Well maybe they're right about that last one
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
I worked on a billion-dollar project where all accounting was done by a huge interlinked maze of Excel spreadsheets. Discrepancies of several hundred dollars were common. The rule was, any gap less than $1k is not worth auditing.
How can you not believe in his rule-of-thumb? Are you saying Brooks was making it up? *He* said it was *his* rule that *he* had used. Don't you believe him?
It seems that you still don't understand what I wrote - there is no dichotomy here. If Brooks had written that he liked to dance a conga before working every morning, and the people from the study *didn't* do that, would you think that one of these things wasn't true? That was your logic. If that's meant to be a joke then I'll keep my keenly underdeveloped sense of humour thanks.
If you think I'm rude then so be it. My post was an attempt to educate you a little about TMMM because it seemed (seems) that you haven't read it well, if at all, but were determined to misquote from it. Your response to this is to call me rude, say I have no sense of humour, correct a spelling mistake, and then for some reason defend your ability to write english. Now *that's* funny!
I don't criticize peoples (mis)use of language unless they ask me to, and I advise you to do the same. However, as you were so kind as to correct me, here are some for you:
you lack of a => you lack a
Touring => Turing (named after Alan Turing, not after long distance racing).
Williams => William (was that irony?)
Mike the oh-I'm-so-rude-for-pointing-out-peoples-mistakes how-will-I-live-with-myself? Wo! Wo!
Tales from behind the Lagom Curtain
Same goes for my high school. I essentially credit for being a part of Journalism while just doing computer work. There still is a serious lack of tech support anyway. Our school (which many people get the impression that it should be filled with working computers, etc. because it is in a influential neighborhood of Silicon Valley) has only a set of rusty Macs to work with for the most part and about one person working on all the computers in the district. I have to fix the computers, tweak them, run the fileserver, code/make the webpage, and assist in all sorts of Photoshop, Pagemaker, and word processing problems. Without students like me there simply would be nobody capable of doing the work. It's so bad in fact that my teacher just refers my services to all sorts of other organizations and schools which pay me to do even more work.
The job is worth it, but it just frightens me how capable the tech support is. During spring break when I was on vacation (our staff is very dedicated), there were printer problems. They finally got the district people to look at the problem when school started again, but they could not even fix it by dismantaling it. All it took was to load the paper more firmly. Another thing is that the teachers want to network the school (right now it is several disorganized sets of cables connected via the district hq miles away) and get some form of e-mail storage, file sharing, etc). The district was supposed to set it up over a year ago but now they're letting me go ahead by just installing Linux. There simply isn't enough competent people working hard to fix all the computers.
One thing comes with simplicity- the inability to fix more complex problems. The article keeps on mentioning how software should be designed for basic use, and that the same software must be bug-free. However, the issue about how power users could not use simplified software has been addressed (one program to do all the tasks rather than 50 to each perform one is much better after all); and simplification also requires more coding. Design is another matter- programmers shouldn't be called on to do it if people complain so much. As for coding, much software requires special features for different users. If some installation or process requires automation, you get more code and more bugs in the end. Finally, simple design is not always best. Case in point- I help out with the Macs at my school, and while they may be simple for using software, it is a pain to install special hardware. All the problems mentioned turn up sooner or later, it's a matter how how easily they can be fixed.
Not only are testing and fixing bugs considered work, they are also considered to be an integral part of software engineering.
The last thing the industry needs is the belief that programmers should only code... oh wait, that is the belief...
A Government Is a Body of People, Usually Notably Ungoverned
Then in that case there would be more debugging, but if there was soo much as to take the majority of the project time, then it probably was a situation where rolling your own to begin with would have been a better solution.
Of course, hitting on the right balance is the key, but the 'should' needs to be more on doing it right to begin with, not with doing it over. Things like unit tests and code reviews working together should minimize the impact of any API bugs. And of course, the programmers should also have a good suite of regression tests in place to make things more and more solid.
A good set of tests by the programmers is one way to tip the balance away from chasing bugs and back to designing and writing code.
http://www.helixcode.com/~miguel/bongo-bong.html
--
You've misunderstood Capers Jones. A properly engineered product will have fewer defects, but a part of that engineering includes testing.
A Government Is a Body of People, Usually Notably Ungoverned
Having worked for Blackbaud, the largest supplier of fund-raising management software, I can attest to the fact that Non-Profits generally do not have more than a few networked computers and rarely have in-house IT staff. Often, they have no one on staff that is more than rudamentarily computer literate. One of my job functions was to restore databases for examination by the programming and QA staff and I can't count the number of times that I received a tape from a client that was marked "return ASAP" because it was their only backup tape. It was infuriating. Now I'm a private consultant and I don't LET my clients get into such a situation. :)
Current trends in GUI design are very damaging from this POV since they further seperate the user from the program, i.e. a smaller percentage of expert computer users have any idea what is going on.
... that it works in the first place. I don't know Anything about cars, but that doesn't keep me from driving it. I just take it into the shop when it needs repairs.
I strongly disagree with this. The whole Point of GUIs is so the user Has No Idea about how it works internally. The important thing to the user is
The whole theory behind GUIs is so people don't have to know how it works. That's why object-oriented design is so popular now; it encapsulates objects, while only giving access to some functions (like accessors and mutators). The programmer who made the GUI should be in control of it; just like Toyota should be in control of how their trucks' engines work with their gasket valve or whatever. As long as the user doesn't know, AND it still works, then the user is happy.
Ignorance is bliss!
-Egon
> 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.
So who's saying they do? Just because there is
no silver bullet doesn't mean it doesn't pay to
think about software engineering.
--
Ben "You have your mind on computers, it seems."
What good does it do for a program to be stable, if it adds together 2+2, and gets 5
This is what getting proper test cases and writing unit and functional tests to check these cases is all about. Good unit tests don't just check that it doesn't crash. They have defined inputs and defined results. Admittedly, this doesn't help if you can't get the user to tell you what they want the program to do, but then they deserve to get non-working software!
Usability is a different issue. Unfortunatly, there is no way to objectively measure usability. The only thing you can do is get users involved during prototyping and let them play with any part of the UI as soon as you can, so that you can get early feedback.
The title of this article is completely ridiculous.
I work for a small company (11 people) providing custom software to government. I am one of the only three programmers, and while we don't spend all of our time developing, almost every moment we spend there is working. Often times, we have to help pick up the slack as far as answering phones, dealing with users, training, installing a new site, or installing and maintaining our own hardware and network. While it isn't always programming work, to say we're not working is totally off.
Testing, debugging, enhancing, etc. is all part of what we do. To say that it is not "actual" work is ridiculous. It's every bit as important, if not more so, than the actual development of our products. Users are much happier if you give them less features (but ones that actually work) than if you give them more features, some or most of which don't work as they should.
As for users using only 10% of features to avoid using features that might break. . . I think most would agree with me that this is a load of crap. With only having three of us to do the load of programming work, it's a struggle to get in all of the required functionality in a timely manner, much less get in functionality that users can opt to not use 90% of. I would imagine that most shops experience this same problem.
And in all the years, you've NEVER had it crash? I love Emacs and use it every day for development. However, I must say that it does crash. Not every day, or even every week. But it does crash.
Well well well...
I know a lot of NPO's that have more then 15 computers. Granted, there are a lot more that dont even have one computer.
Take some org like UNICEF, The Red Cross. These guys have networks that would make any decent sysadmin drool all over himself.
OTOH, I have a sister that works for a smaller NPO, and they have a +- 20 computer office.
They budget for maintenance on them, and dont let them grow old.
That covers most problems.
Personally, I'd be willing to donate my time to maintain such a network.
If I could deduct my time as a "donation" to charity, I'd be even more inclined to do so.
Being that my average consultancy rate is around 85$ / hour (yes, I know, I'm cheap.), 2 hours/week @ 85$ = 170$ * 52 weeks = 8840$ tax break (give or take a little.).
This way, everybody wins. They get "free" support, you get tax relief, and someone in the end (in my sister's case, a whole lotta kids) get free services.
If this does not exist, it should. Anyone up for "sysadminforpeace.org" ? =)
Marriage is considered capital punishment for the theft of a goat in some third world countries...
Photoshop (by Adobe) works in much that manner - it has a simple(ish) core, tons of plugins, and is used by professional graphic artists all over. Shame it isn't availble for *IX...
--- The key to knowledge is not to rely on people to teach you it ---
I marvel that if Microsoft is so interested in innovation, that they can't "integrate" a basic word processor with spell-check into the operating system like they can a browser . They must be too busy inserting Pac-Man and Flight simulator easter eggs into their products to give a damn about what most consumers would like. Microsoft feels that you are entitled to get the features you want in an operating system integrated. More people want a simple spellcheck-capable word processing program included with their OS than want an integrated browser. Microsoft is in effect saying that it is ok for the consumer to get what they want bundled in their OS for free. That means it is OK to pirate Office.
Game: Player 'Donald J Trump' now has AI skill level 'experimental'.
(end comment) */ }
(end comment) */ }
[an error occurred while processing this directive]
1)The rest of their time, about 150 days, is spent on testing, fixing bugs and working on projects that are later canceled.
O.K., I might allow the working on projects that get canned not being counted as work (even though they are work. ask someone who worked on a project that was canceled.), but testing and fixing bugs not work? Does he believe that code should be written, compiled and then work perfectly? I've met developers with the attitude of, "well, it compiled without any errors. Lets put it in production." If you have never worked with someone in this mind set, it is scary, and a difficult arguement to win to boot.
2) Reminds me of another survey I saw with similar results. It said that American developers write about 4000 lines of code a year (compared to non-US coders producing 16000 a year). I don't do development primarily, and I know I've written a couple of thousand lines of code in a week (not including comments). I guess that fixing code (like in the story) wouldn't count as "code" either. Even if you have to add lines.
This article seems to be saying that poor managment leads to unproductive programmers. Any innovation in code should be planned, coded, tested, evaluated and have the process started again (from step two). Give developers some credit.
Still, with a plan, you only get the best you can imagine. I'd always hoped for something better than that. -CP
My, this really sounds stupid to consider coding and testing/debugging as two distinct tasks.
As fas a I'm conderned, I'm gonna spend the next 365 days writing code non-stop, adding functionnalities each time I think of any, and I won't even try to compile or run the software untill these 365 days are over. Then I'll send my code on the Internet so that other "less productive" developers test and debug it, and because it will obviously turn out that all this code is an awful mess that can't be debugged, I'll claim that the rest of th world is outrageously improductive. Deal?
90% of all statistics are made up. I doubt anything will change in this area for a long time. The real reason software is so arcane is that software companies make it that way to try to enforce their proprietary standard, or just to add an extra buzzword to their marketing crap. Add this to the "need" to support protocols and applications all the way back to the stone age and your software's complexity can only move in 1 direction.
Of course, much OSS is far simpler by comparison, but because it doesn't have a nice GUI and an ad in a magazine, regular users think it's impossible unless you're a computer freak. I've lost count of the number of times I've tried to explain how I did something and got the response "Urgh, I don't use command lines". Not that they're any good with their fancy windows software - reading user manuals and computer books seems to be another lost art.
Not that I'm complaining - the worse the software is, the more I am appreciated. Crap software - where would we all be without it?
Now, is this yellow journalism? Possibly:
It's not necessarily an invalid opinion, but I'd venture to guess that it's there for pure sensationalism.
As far as the main point of the story goes, I think its truthfulness is limited to organizations without clue. Notice that they are complaining about "obscure checkboxes" (on a Mac, no less!), "technical support", "unfamiliar features", and "comfort level". These are the complaints of a person who fears computers and has not yet mastered them.
Now, this epidemic may indeed apply to most organizations. Sadly enough, it seems to apply to most I've seen. Schools, especially, seem to be bereft of clueful people. (Is there any way to volunteer to be a part-time sysadmin at a local school?) Even one person who knows how things work can make the system run smoothly, if others are willing to listen to that person. Too often they aren't.
As far as programming, I have an important note to make. This "study" (it'd be nice if I could find out some more information on how it was conducted) seems to imply that days of work and productivity are directly related. They're not. I, and most coders I know, work in bursts. Inspiration strikes, and you make a leap forward in an hour. Other times you sit for days. I have to suspect that Brooks would agree that making productivity measurements directly on time is baaaaad.
It is true, though. Bug-fixing and meta-tasks take up way too much of our time. Sometimes it's our fault for not writing correct code, but sometimes (and often!) it's the result of pressure to get it into production now! Customers need this feature! Quick quick quick!
Finally, they neglected the most important influence: morale. At work, there's some stupid stuff going on, and the project I'm on is one of those "we know it's a bad approach... you were right about that... we'll fix it later, though..." things. There are times when I feel completely ready to code, I'm sitting at the keyboard, and yet nothing comes out because things are so depressing.
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
"I can do 5 at home by myself.."
You have five people using them concurrently, eight hours per day? That can make a difference... and can make for a crowd in your house!
Everyone will start to cheer when you put on your sailin' shoes.
I've been espousing for quite a while, the idea of Smaller Applications. As more and more "features" are added to Office, and as the applications therein are more closely tied to each other, and to the desktop (and IE, bleah) they become more and more cumbersome. One corrupt file no longer breaks a single application, it can break half a dozen. I can't help but wondering how much of the end user functionality could be done away with. In my experience, very few users will ever use for instance Word for anything more than text editing and formatting. Wouldn't it be easier to have a universal format for TEXT and just have small applications that interpret that format differently for different needs. I could see someone extending HTML to this sort of use.
"42"
No, not coming up with, but they should be reviewing and planning for changes. You don't need to over-engineer, but if a programmer knows that things can change, and then keeps that in mind and looks for ways to minimize the impact of changes, then things will run better. Also, any programmer who doesn't think about the "why" of his task and only the low-level "how" to implement it is probably not working at the 'should' level that was mentioned.
I believe what should happen is that good programmers will be able to recognize poor design requirements. Then they should know to take this to management. Management then should be able to take things back and get things clarified.
And there I think you hit the nail on the head. The projects I've seen that have had the most trouble have been those where the programmers did not get enough time up-front and/or did not follow up on getting good requirements. An experienced architech will be able to recognize those poor or rigid requirements and get to something better. That is, he should be able to from experience notice when something is wrong and then know to wade through what the client says he wants to go to what the client actually needs.
Notice again that I'm talking all about 'should' and not just blindly stating that it has to be so. I'm quite aware that in many situations it's not. Often the problem is that there's never time enough to do the job right, but always time to do it over.
I'm a software developer (programmer). I work hard. But I can easily say that 60% or more of my time isn't spend programming or even bugfixing. Most of my time is spent investigating technical issues, hammering out new feature refinements and specifications with program manager and designers, teaching myself new skills, writing documentation, attending meetings to coordinate ongoing work and scheduling with team members, and other such things. These are all essential parts of a programmer's job, even though they aren't the actual act of coding.
As for the statement that was made about users being "afraid" to use the wealth of features in a program because they think some bug will surface, that's total nonsense. Usability studies show that most users don't use the features because they aren't aware that the features exist or simply have no need for the features at all. In the first case, the lack of feature visibility is entirely the fault of the designers of the feature; and in the second case, there's really no problem if your software is architected correctly (just because a new feature exists in a product, that doesn't mean it should take up memory and slow the execution of other, independent features in the product if it's not being used).
Of course, the ultimate solution (as I saw someone point out here earlier) is to design software to be as componentized as possible. Don't need a certain feature? Don't install that component. Saves disk space.
- "It's just a matter of opinion!" - PRIMUS
Come on, are you real programmers? if you work on any hi-tek company that trade on NYSE you are going to be expending the next lifetime at the office, no rest ever comes to you!!! so whoever wrote that article: get a new job!
-- Always Encrypt. If it's probably secure, it's probably not... (Lars Knudsen on block ciphers)
What we know as coding is an iterative process of micro plan, micro design, micro test, micro modify - unless the tech spec contains the same or more information about the finished code than the finished code. The more effort studies like this take to micro analyse the work done, the less and less work will appear to be 'coding', until what you are left with is the time spent working the controls of the computer. 47 days is a long time to be clicking and typing - maybe we should be trying to reduce this figure, rather than extend it.
And yet in all the years I have used Emacs I have never had it crash one me
/tmp when running it, then...
You've obviously never unmounted
I wonder if that's been fixed. I haven't tried it recently.
Neil.
The only reason some of the features are included are to give people more options and as selling points.
I worked on a program where we'd had creeping featurism to the point that the program was rather bloated and fragile. Our distributors kept telling us we should stop worrying so much about new features and clean up the base application.
So we did so. During the beta testing of the new version, one of those same distributors sent us an e-mail telling us how the clean-up and interface improvements were great, but couldn't we add some more new features?
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Then again, it's probably because i'm a non-believer in management strategic abilities ... *sigh*
> One of the figures lies, or we work more than 11 man months a year or we don't drink coffes at all.
I hate to be rude, but another alternative is that you can't read. What you didn't quote is the sentence immediately preceding Brook's list. It reads "For some years I have been seccessfully using the following rule of thumb for scheduling a software task:". You'll note he says "I", not "most people", or "the industry in general". If most poeple followed more of the advice in TMMM then perhaps we'd all be better off, and the figures in the survery would be rather different.
Mike.
Tales from behind the Lagom Curtain
No, I don't HATE it that much; I just don't find it THAT interesting (even though I like to write my code optimally, so it works much more efficiently) after 10+ years.
;-) programs/systems.
/. :-(
IMHO, the only other interesting part of programming (besides the optimization as distant second) is the Algorithmization, i.e. resolving the problem and creating a computable algorithm.
And this is the thing I'm proud of, here my bragging rights lie. No one (but some stupid managers) cares how many screens with entry forms you've coded in the application; clever ones are more interested in some proof how you've translated complex business problems into working (optimally working preferrable
Bad side is that it looks like my 47 days have already expired for this year; so, I waste my life at work by reading
Tigers respect lions, elephants and hippos. Maggots respect no one. (C) S. Dovlatov
> What other 1/6th were you talking about?
These are Brooks figures given after this sentence "For some years I have been successfully using the following rule of thumb for scheduling a software task:".
So the answer is, It's a rule of thumb, giving general quanities. An even more pedantic answer would be to point out that the values are for *scheduled* work, and therefore he is free to leave a certain amount of time un-scheduled to allow for project flexability.
Mike.
Tales from behind the Lagom Curtain
I'm spending more of the time debugging and cleaning things up than I do when I'm first writing the code.
No offense, but if that's the case you're not doing it right. You need to do some design before you code, or at least do a prototype that you throw away. Coding straight out of the gate will only lead to endless nights of debugging massive piles of spaghetti code.
the first link in the story is one to the topstory today of the la times.
Top stories change, you know... so now your link refers to some story about cellular phones.
I don't have time to look things up (at work, one of those 47 days per year)... could anyone provide an accurate link to the story ?
Mike
not to mention that non-profit is a broad category.
Even still, the #s are pretty poor. I'd wager though that the numbers are bad not b/c programmers aren't working, but b/c sys admins are too expensive for a NPO to have too many. i also think its a mistake to equate programming and system administration. Those are two very different things.
Big nonprofits, like the Smithsonian are the exception, rather than the rule. They may account for lots of computers, but they're only one entity.
`ø,,ø`ø,,ø!
Free Software: Like love, it grows best when given away.
I worked in the tech. dept. at my high school for high school credit (and a little something for my resume). We had roughly 150 computers (it was a small school). We could definitely have maintained all the computers between the one Technical Coordinator and two student technicians. In fact, we completely revamped every computer in the school in a week (remember: the two students were only working 2 hrs/day). Aside from that week, though, we let the problems build up until we couldn't stand the complaints anymore. Our problem was a lack of motivation. We weren't being paid a huge salary like our friends working for large corporations. The trade-off? We elected to be lazy. From an employees point of view, it is overly fair. It's sad, but it's true.
I don't think Quality Control (QA) has much to do with debugging, but everything to do with testing. Debugging is an attempt to track down a problem, is almost always done by the developer in response to a bug (probably submitted by QA). Development and debugging go hand in hand. Now testing is another matter. Having developers working on testing can be a costly waste of resources.
Someone you trust is one of us.
All this article presents are problems. Commercial software quality sucks. We already know that. Too many bugs end up in fielded applications forcing developers and tech support to expend extra effort. We already know that. Users only use 10% of features in large applications. We already know that. There is no silver bullet. We already know that.
We already know all of these things. So, where is the solution? As Brooks points out, it isn't in the process. To find a solution, we need to look at the cause of the problem.
The software industry rewards companies for quick production, not quality results. Quality doesn't effect market share. Furthermore, users only find about 10-25% of bugs that are shipped. Rather than try to reduce the number of bugs preshipping, many companies choose to focus on fixing the few post-production bugs that a large number of users support. The cost for tech support, programming, redistribution, and spin control can be less than the cost of testing, design, and programming to remove the majority of the bugs.
To change the software industry, you have to change the environment in which it operates.
Testing and debugging are just as much "software development" as writing code. Just like design is an essential part of development.
Unfortunately certain large companies with headquarters in the Evergreen State don't seem to believe that design, testing or debugging is part of developing a product....
(The real question is: what percentage of a programmer's time is spent surfing the web, downloading MP3's, playing games, ...) (Not that those are bad things - if we couldn't do those things at work I think programmer productivity would plummet.)
Unlimited growth == Cancer.
This is not a problem of how difficult it is but one of skills. My dad would tell it's a breeze to completely disassemble an engine and put it back together again but I have to constantly help him with his single computer. I on the other hand can just barely change my oil but I maintain a network at home, at my office, and at my parents office.
These NPO's are full of people who just want their computers to work. They don't have the time or the inclination to figure out we take for granted. But then what they take for granted may baffle us. What seems uncomplicated to us because we are immersed in it is incomprehensible to those just trying to complete a grant application and print it.
The bottom line for NPO's is: can they afford to pay for tech support? Looking at some of the invoices I've sent out just for network maintenance and knowing from the inside what an NPO's budget situation is, I'd say 90% of NPO's can not afford the level of tech support necessary to maintain 15 computers that are being used by people not capable of maintaining them themselves.
Let's do the math-- if 47 days is 10% of your work time per year, then there are 470 work days out of the 365. Well, we work long hours, so say it's a 16 hour day on average, for the 4 days of a 50 work-week year, that's 400 days. Still short 70 days somewhere.
No, I'd say the average programmer spends maybe 20days a year writing new code. 47 seems way too high.
-dB
"It if was easy to do, we'd find someone cheaper than you to do it."
I saw that portion and I thought it was a little ridiculous. It's just like any other sector, non-profits run the scale of size of business vs. computing that any other company does as well. I think that it's just that technology isn't always the first place to spend money for smaller non-profits. Most non-profits are of a much smaller size as well. Although I feel that is turning around as I get more and more requests for help from non-profits.
--And sektor spoke and said unto the people. Hey, buttwipe hand me the cheezeos.
This is a very interesting point, but I don't think it will help with the problems the article describes. The article is partially complaining about how software is not easy to use, but any powerful set of tools will necissarily be more abstract. You may remove the feature bloat and allow all technical people to be competent in a wide range of tasks, but stupid or unskilled people will still be stupid or unskilled.
I think there is a kind of Church Turing Thesis which applies to this: You can choose between using a blender or using a computer. A blender only dose a few things, but a cmputer's interface must be a programming langauge (or else it's a blender).
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
If only 10% of the functionality of the average application gets used, then the problem with making a scaled-down version is that if you have 10% of the original features, then users will only use 10% of the reduced features, or 1% of the original features.
-MR
-Michael Roy Some people are like Slinkies. Not really useful, but you can't help smiling when you see one tumble down
so this thing is implying that bug-fixing isnt working?
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
Well, a lot has to do with whether or not the non-profit is swimming in cash, and where their priorities lie. Most non-profits can get semi-decent hardware donated. But this frequently doesn't include any software licenses, so if they want to be legal and run Windows, they have to pony up the cash. And the creep of new applications puts the pressure on to upgrade applications, which sometimes means a new version of the OS, plus better hardware.
Some non-profits have a very healthy cash flow, and are able to take advantage of technology, and spend money accordingly. Others recognize the potential benefits of technology, but don't have the cash to put it in place. As an example, animal shelters can make great use of computers, but if the available money can either go to computers, or to pay someone to shovel the shit out of the pens, well....the shit shoveling has to be done, the other stuff can be done the old-fashioned way.
Keep in mind that many non-profit jobs are low paying, and you don't always get the most computer literate people. Turnover is frequently high as well. This leads to a training nightmare, along with system problems caused by clueless users, and supposed problems that are really just the user making a mistake.
JavaBeans address much of your issue, along with all those ready-built COM/ActiveX components you see for sale in the back of DDJ.
I don't know of anything like this for Unix yet, but Bonobo might be promising. It takes a lot of time for something like this to reach a critical mass, though.
That said, I do think most programs have too many features. They all want to make your friggin coffee in the morning when I just want them to do a simple task.
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
I'd have to disagree with that. If a programmer is doing his job right, then he should spend time at the begining setting up tests but that's mainly it. Spending a lot of time after the fact trying to ensure the job was actually done correctly, or trying to track down why it wasn't should not be a major part of his job.
I know XP takes this to the extreme, but the basic principle holds true. If you're spending too much time debugging, then you might not be spending enough time on solid design and correct coding or even just determing requirements before working.
In other industries this is known as "measure twice, cut once" and the like.
Not only that, but while new versions may not be available on Unix, Photoshop is available in older versions for Unix. Not being a pro, and having used both, I find GIMP does everything I need.
----------
Stupid sexy Flanders.
This is what makes me glad I switched from being forced into becoming a programmer to doing networking... At least networking is straighforward, but this sounds... well almost governmental (& governmental==nominally ineffective)...
we are all invisible unless we choose otherwise
I imagine this situation to be pretty typical for NPOs:most of them are small enough that 15-let alone 50 networked computers would be a complete waste.
Things is, it's a different 10% for each user. MS word tries to display only commonly used features to users by collapsing menu items not used often. Neat, but annonys me.
Rocket science is easy. Neurosurgery, now *that's* difficult.
I volunteer with the United Way as a technology consultant. Bassically what I do is go into participating nonprofits and help them determine their technology needs. Nearly every single nonprofit I've gone into has had little or no computers. One of the companies I'm working with right now used to have a Mac SE until someone broke in and stole it 3 months ago, now they have nothing.
Get involved. Do something for your communities and stop plaing so much ^&*^^&$$3$#@#@ quake!
I don't think they're trying to say that time spent debugging isn't considered "work"
He compares the time for "developing" with that for "testing, fixing bugs...". Later on he whines about the low quality. Well, if I don't see testing as part of development, then the quality will go down, not up.
- obviously it is, as fixing problems to make a stable product is an extremely vital activity (as we all know)
Yes - WE all know that, but he doesn't seem to. That's what angers me about articles like that.
What I think they're trying to say is that a lot of our debugging time is spent dealing with stuff that shouldn't be a problem in the first place
If we test less at the beginning, then we will get more unnecessary bugs. Again, to us this is a trivial statement. But to me, it seems he has taken on his own advice:
Programmers should code - so they should spend less time testing and debugging.
Writers should write - so they should spend less time researching.
47 days working.
250 reading slashdot.
One thing I think should be done more is writing software in reuseable components. That way, if the project gets canceled, you still get something out of it: perhaps you have implementations of a bunch of algorithms which you can just plug in on the next project or something like that.
That way, the work on your canceled project can be considered as work on other projects you hadn't known about when you did it. And if your project doesn't get canceled, you've still gotten more use out of your time spent working.
Non Profits in my area have next to nothing as far as computers go. They have 486's if they have anything. So that everyone knows it does not matter how people work in an angency it is what the agency is set up to do that matters, for counting how many computers they versus how many they need. If you have 5 people working there, but they have 30 thirty kids who come in and want to us computers maybe they need more than 5 computers.
2 + 2 = 5 is a bug too. System crashing bugs are harder to work out 2 + 2 bugs. Proper unit testing can greatly, immensely, repeatably and productively reduce the number of 2+2 type bugs that occur.
Using a systematic defined approach to development, by following a formal methodology, with good communication between team members, will reduce the number of bugs in your code. Unit testing should be part of that methodology.
Example methodologies : RUP, FDD, XP, DSDM - all of them properly documented, in use, improving the quality of code.
None of them are magical techniques. None of them need code gods to implement them. Most (all) of them need good communication between team members.
Linked to those (and built into some of them) are additional techniques aimed explicitly at code quality and bug reduction - code reviews (or pair programming), following good coding practices and coding standards, making use of patterns and re-usable frameworks and components.
Fred Brooks said there is no silver bullet. I agree. But there is a lot of lead out there, so don't ignore it, use it, and you will get the benefits, and your users will thank you for it. And that's a nice warm cuddly feeling.
~Cederic
More to the point, the users will always decide they want things to work differrently once you've written the software - until they've seen it, used it, played with it, they don't know what they want. Maybe in a highly controlled environment that doesn't hold true, but in the business environments and leisure activities where I've been involved from an IT angle, that's always been the case.
So write the code in an easy to modify manner. Good design, good use of patterns, well written code, a good set of automated tests will allow you to make changes to a small part of the system to reflect a change in the requirements from your users.
Anticipate that they're going to want change, and don't write code that wont prevent it. Anybody who is a good software engineer will tell you the importance of maintainable code - stop and think why that is.
~Cederic
My, this really sounds stupid to consider coding and testing/debugging as two distinct tasks.
You betcha. Your reaction to avoid testing and debugging is wise my friend because testing don't get no respect. That's why people avoid testing. There's no glory to be had. Debugging is only one step up from testing. You can spend days spinning your wheels and then, in a 10 minute period, figure the whole thing out and push a fix. People just refuse to respect testing and debugging. Those activities are regarded as contemptable and those who perform them well are often relegated to a lower "caste".
Wansu, th' chinese sailor
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.
The thing about users only using 10% of an app is probably true. The problems with using this 'fact' to promote less featureful programs are as follows:
Why do you think manufacturers put bullet points all over the box? Features are the only easily quantifiable selling points.
Also, manufacturers are motivated to reach the widest possible audience, to get the highest return on their development cost. Additional features are perceived to cost very little, and thus it seems attractive to add features to reach more market segments.
The only solution to bloatware is to successfully communicate the actual cost of adding features, in terms of exponentially increasing debugging time and, inevitably, more bugs at release.
The same researchers who came up with this study went into other fields hoping to improve efficiency, and came up with these remarkable statistics:
- In the food service industry, waiters and waitresses are spending a distressingly small percentage of the time serving food. In fact, more time on average was spent simply taking the order. The median time to get a meal to a customer was just 10 seconds, showing that the food servers have mastered the art of taking food from a tray to a table, but are still lacking in doing this efficiently
- Engineers were found to spend a considerable amount of time "testing" their potential designs, hurting their cost-effectiveness when their products could have gone straight to the market without this in-between step.
- In a very disturbing trend, medical doctors seemed to only be treating their patients a remarkably small percentage of the time. However, new techniques may make the "diagnosis" stage a thing of the past. Future patients may be treated for a disorder before they knew they had one (including glitches like broken bones, decapitation, ebola, and autoerotic asphyxiation). The fact still remains that doctors have a 100% failure rate among patients when viewed in the long term
So, he assumes 197 work days a year. Of those days, 47 or 24% are spent developing and 150 or 76% are spent testing, debugging, or enhancing software applications. I would think spending 24% developing sounds about right. Also, his statement "enhancing software applications" is a big generalization. A little more details would make his statements more interesting.
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
Canceled projects can also be considered wasted time, IMHO, because in the end, there is nothing to show for the work that was done. Sure, your team did a crapload of work, but if someone scrap's everything you've done, what was the point in having you do it in the first place? Was there not something more productive you could've been doing than working on essentially trash? Yes, perhaps your team has gotten a bunch of new skills, and that's great, but usually they can also do the same thing in something called "training."
Personally, I think there is a whole ton of wasted effort going on in the working world, but everyone involved is in such massive denial about it that nobody attempts to do anything about it. While I think this study is a bit extreme in its estimates, I hope that it induces some change for the better in terms of productivity.
47?! Do you people realize the significance of 47?!
Connah
Connah
"Your mouse has moved. Windows NT must be restarted for this change to take effect."
heh - that's *IF* you believe everything you read. and what happened to the other 1/6th??
witty sig goes here
Surfing over to /. and taking the piss out of Cowboy Neal of course!
UNIX? They're not even circumcised! Savages!
- 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:47 * 6 = 282. Which, given the overtime, sounds about right :(
But anyway, the whole slant of that article w.r.t. coding vs other things is silly: A car development engineer might only spend a few weeks a year actually thinking up new stuff - the rest of the time he's refining the engine, setting up testbeds, testing the engine, evaluating the results of the test, retesting, modifying the test environment.......
Thinking of or writing down new things isn't usually the issue with engineering - it's testing, making sure things work.
As for the cost of running a network... true. There's a lot of accidental complexity in that, which we should work out to make it accesible to more people. However, the same nonprofits wouldn't expect to run a fleet of 15 vehicles without occasional recourse to a professional mechanic, would they?
Another thing I'd like to know is how many of the non-profits are big enough to need a network > 15 Computers anyway?
no taxation without representation!
said "There are lies, damn lies, and Statistics"?
I mean really, 90% can't manage more than 15 computers? I can do 5 at home by myself..
Why is this comment labeled as 'funny'?
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
Most modern SW Engineering models include traceability from one step back to its predecessors. They also increasingly emphasize the requirements phase as the most imporant part. It's all about the interface.
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.
Ahhh... nothing like getting rid of BLOAT!!!
The URL for the story on "Programmers work 47 days per year" has changed from http://www.latimes.com/business/columns/techcol/to days.topstory.htm to http://www.latimes.com/business/cutting/20001127/t 000113753.html
If you know what you're doing, you're not learning anything
MS Word is a blender.
I totally agree, but I was sorta saing that there should be no MS Word. I was mreally tring to imply that there should be no applications / basic interfaces execpt for really disguised programming / scripting langauges. MS Word would just be editor, spell checker, pretty printer, etc. libraries.
I'm not really shure that it matters if we make computers easy to use for the masses since the masses will never have more then a blender even when they own a computer. Fundamentally, we should care about how much the computer entices people to learn more about programming it since this controls how many people we have to maintain the blenders for the masses.
Current trends in GUI design are very damaging from this POV since they further seperate the user from the program, i.e. a smaller percentage of expert computer users have any idea what is going on.
I'm literally talking about using a shellish langauge to write the interace, but have a shell prompt at the bottom of EVERY programs main window. Pull down menues would just be cut and paste short cuts to shell commands (ala Plan9). No one would know that you could just do things directly unless they knew what was happening, but they could start plaing arround and learn quite a lot without forests of confusing menus and icons. Most importently, every program would be very flexible.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
if I use 10% and you use 10% and those 10%s are different even by only 1/2% with 1000 users it's conceivable that 90% of the functionality is used.
so which 10% do you work on?
I agree with the positive outlook on this. There are too many programs these days that are sooo frickin huge that all quality is just lost. Take IBM's WebSmear for example. It's footprint is, well, however much memory you have!! What the hell kind of design principle is that? I work at a very old government contractor and the higher-ups here can very easily be mislead by clever marketing by Big Blue et. al. But it is important to have reliable software when you are developing for the DoD, and not all of the stuff cranked out by these large companies is good, to say the least! Hence I think that all of us in the development business should take a two hour break every year and read Mike Gancarz's book, the UNIX Philosophy. It's not about UNIX, it's about good software engineering.
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".
You are quite right.
Although I don't program in a compiled language yet, I've seen myself fall into that trap.
I ended up trying to solve a problem I didn't even need to have in there.
From that point on, I took time to comment what I needed to do before I wrote the first line of code.
I hope this helps someone.
There: Something at a specific location.
Their: Owned by someone.
Please make sure your english compiles.
technically, i work for a "not-for-profit" organization (a rather large hospital).
for the systems that my group is in charge of we have 100 aix servers, and the application runs on approx 1100 pc's and x-terminals. all networked, btw. and i know there are thousands more.
personally, i don't think we act much like a nonprofit, but i don't know the laws.
One of the things that makes importing foreign formats so difficult is that you almost have to support every feature the foreign product supports, or it won't import correctly. Don't support watermarks? Funky table alignments? Post-it-notes? Then it's never going to import 100% correctly.
Am I the only one here that never debugs my programs after they `work' for me? I run my programs and play around with them but I never try to debug unless something isn't working properly... Do you think it could be because common lisp and other higher level interpreted languages can help solve some of these problems?
A few, admittedly highly cynical observations, respectfully submitted:
This article is the typical mishmash of clueless quotes, half baked whines and self serving statistics that we all know and love from our friends the papparazzi. It's no better or worse than hundreds of others. I believe the slashdot community is one of the few that knows this, it's not really worth much of our time responding to these kinds of silly know-nothing opinions. That said, I'm going to anway dammit...
One truth (apparently accidentally) embedded here is that most projects should be killed at inception. As most of us know, projects are started by users with no idea what they want, which is frankly understandable, to a point. They are then ably aided and abetted by the common variety of clue challenged technology management teams, too weak to question them or help them figure it out. There's no motivation to challenge or help the users get focussed, because most managers are never measured or held accountable for the time they waste. Why not?, because managers being humans (yes its true!) are very careful not to measure the number and dollar cost of their failures.
I believe that an innovation we need is not some new language, tool or OS (even Linux), but a simple and practical project killing methodology. Basically, software development teams need to consider all projects a waste of time and money, until they are proven to have a viable business case and clearly achievable design. Middle management opinions should be considered inherently suspect. Failing all else, they should document their concerns and make sure these are noted by the CFO when the inevitable failure occurs. If you ever try to do this, you will probably be told its not your problem and the users/leaders/daddy knows best. If you ever hear this , its a huge red flag and clearly bullsh*t, given the failure rate. I consider this a perfectly ethical response to gross mis-management, for which developers are incorrectly blamed.
Remember, the fox is guarding the chicken coop. I believe that most management teams secretly love to have a huge backlog of support and bugs and many understaffed, under-planned, slowly failing projects. They are arsonists, who love to run around being hero's putting out fires they secretly started. Preventing the fires is no fun, and too hard, doesn't get you visibility or promoted and forces you to clash with ingrained cultures and cynical developers (yes that's us). IMHO, this is an un-virtuous circle that lies at the heart of the so called software problem. That is, there isn't a software development problem at all, there is a software development leadership problem of enormous magnitude. I know, I am one (d*mn, how did that happen!, I used to be a real developer honest..).
I am very doubtful that this problem is truly fixable. I believe it isn't because of the nature of human organization, the way technology projects are initiated and the inbuilt motivations to leave the situation the hell alone. These factors are built in, process improvements are transient and subject to entropy, in my experience they all fail, given sufficient time. That doesn't mean don't improve things, it means expect it to be temporary and won't matter much given the meta-chaos just described.
Finally, I believe the business and academic crowd, though fun and entertaining to watch, are fundamentally out of touch with what we need to fix this. They are inadvertantly contributing to the problems and confusion with silly research, bogus stats and idealized impractical methodologies. They mean well, but they can't openly grok whats going on.
Ok, I feel better now, gotta go, there's a new, cool, top priority, mission critical, must be done, greenfield, fully buzzword compliant project just starting. More sharp acronyms for the resume. You want in?...
Gotcha!
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
Let me see you pay me ~1000 dollars to set it up a nice little Samba server a Internet gateway and pull the cable. Use a simple switch (on that size network you don't need much else). Then ~200 dollars a month to maintain it. I have several that size I make money for about an hours work per month and they are happy. Oh wait I forgot these people are trying to use Winders on servers. Yup it would be much more then.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
From everything I've done and seen, debugging a program is often more difficult than programming it in the first place. Some of my friends spend 3 day straight binges doing nothing but bugfixing and bughunting.
Sounds like work to me.
-CoG
"And with HIS stripes we are healed"
-CoG
"And with HIS stripes we are healed"
Handel's "Messiah"
Part of the issue is that it is hard to recruit techies to non-profits because of the pay - but in reality there are two major reasons: (1) A lack of recognition that an investment in technology infrastructure can, in the long run, save more money than is spent. Unlike the for-profit world, the mentality is (mostly because of necessity, sadly) penny-wise and pound-foolish. (2) Governmental agencies and private foundations don't like to give money to either technology infrastructure or personnel, only direct service. So non-profits that depend on grants are up shit's creek, they simply don't get enough money to invest in the technology, whether it be buying hardware or paying someone to run it.
I think that linux and open source software is one way to decrease cost of ownership - we've been working on evangelizing with local non-profits. But it's an uphill battle, because many of the managers of non-profits aren't technologically savvy, and don't know how to evaluate all of the options.
Programmers only work 47 days a year--- It's just that they're all 48 hour days.
DAILY ROTATION
I'm sick of hearing the same crap. Whenever somebody makes a sweeping comment about software consumption, half the slashdot population respond with their two cents about fine-tuning VI or some other nonsense. The point is that while mass produced software is sold on the basis of endless options LISTED on a shrink wrapped box, it is widely used in a cautious and naive manner. YOU don't come into it at that level. None of you. You are all pros, your efficiency is based on flexibility at a complex level... usually in a development environment. VI, emacs, blah blah are all perfectly suited to your needs. This is one of the biggest shortfalls in software engineering: programmers programming for themselves, rather than for the end user. In the end I think that the problem that the article is getting at is that these end users will not buys simple software because they think it is a waste of money.
The arguement runs like this. Anything other than writing and enhancement does not better the product. Anything that does not better the product is waste.
The notion that people may spend great amounts of time securing the position (eg debugging, building foundations, etc), or recycling waste (eg learning, trying things out, discovery) seems not to be `productive' and is thus not `work'.
Same as any other commercial activity - they say you can run the ship in fair weather with a crew of x, so that's all you need. Tough if the boat sinks.
OS/2 - because choice is a terrible thing to waste.
Ken Olsen, founder of DEC, was once asked how many people worked there.
"About half."
I'd like to know so I can schedule my annual leave for half of them and pull some sickies for the some of the others.
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
I'm curious if they had a breakdown of the amount of time spent by engineers ranting on /.
- 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
If you spend more time up front making a solid product, you don't spend time on the backend fixing it.
Fight Spammers!
How big are most non-profit organizations? Assuming one computer/person, that's a 15 member organization, if they all need to use computers. However, in some cases (such as a local animal shelter), I could see a use for maybe one or two computers for records and book keeping. The law of diminishing returns then kicks in, by giving an animal shelter another computer, little benefit is realized. I'm curious what they mean by when they say 90% of organizations can't afford to network more then 15 computers. Do they need a network of more then 15 computers? If so, what type of network do they try to buy? Does someone try to sell them state of the art 1 gigabit ethernet and switches when all they need a 10 megabit ethernet and a few hubs? By itself, the statistic is almost meaningless, we need other statistics to draw a conclusion.
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."
If MS froze the feature set of Word, MS would not be able to sell any more copies of Word...
Especially since most bug fixes are distributed as free patches.
"MS WORD 3000 - More Features - Now You Can Do This! - Fixed Bugs!"
- is more attractive than -"MS WORD 3000 - Fixed Bugs!"
I say give me a small, stripped-down utilitarian software package where I can pick & choose the level of Bloatware to put up with.
Like, give me Word so basic that it rivals WordPad... or even NotePad -- and then let me pick and choose how slow/bloated/buggy I would like it to be.
"C'mon, donkey-boy!!"
Crystalize your tears, dried upon The Cross
Blood drips on your pain, time to ride The Light
In case anyone tries to read the story after 11/29, here's the URL:0 001127/t000113753.html
http://www.latimes.com/business/columns/techcol/2
As a software engineer, I understand why so little time is spent developing new code. The more code you have in production, the more time you spend supporting the users. Between coworkers who can't figure out how to access a network drive and users who don't know what software that they spec'd out themselves does, I have very little time in any given day to write code. I write code maybe two hours a day, and either handle service problems or overhead items the rest of the time.
It's discouraging, but unavoidable in this field.
Maybe they meant 47 straight days in a stretch. Maybe thats just DBAs, dunno.
Icebox
AH! You have the intelligence of a jar of mayonnaise! They didn't say debugging and such wasn't work. Programmers spend 47 days per year "developing and enhancing code." That however, does *not* mean debugging. That is work, of course, it's just... ugh. nm.
------ This is my sig.
Quite probable that within specific areas the public and private examples transpose, as I've seen examles of that, too, doing one years work in 3 months (just before quitting) at a college.
--
A feeling of having made the same mistake before: Deja Foobar
It makes a lot of sense, actually... Have you looked at any piece of software recently? The linux kernel supports so much more than it used to, and don't begin to think that it didn't require testing to get there. :-), and so on.
Same goes for most things, be it X, Mozilla, MS Windows, etc. While I refuse to make a statement regarding the quality of any of these pieces of software, they all have a lot of features that we'll rarely, if ever, use.
Same for a few obscure vi commands, random crap in MS Word, half of emacs
It's just the way things work. Remember, most packages did start small. Then they got hit by the "wouldn't it be cool if?" syndrome.
Raptor
Raptor
"Procrastination is great. It gives me a lot more time to do things that I'm never going to do."
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.
If I recall correctly, OpenDoc wasn't necessarily
tied to a specific language or platform. It was a description of how to write container apps and objects. A spec, which Apple produced an implementation of. I think a company called Digital Harbor actually produced the theoretical word processor.
I've heard you can do most of the things that OpenDoc did with Java, and perhaps other languages. True?
And if so, why not try and create such a thing?
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
Clarisworks (now Appleworks) works FANTASTICALLY on all of the Macs I support. I reccomend it to everyone who wants a word processor, spreadsheet, whatnot - for their Mac's at home. Works fast and efficient (for a Mac), and doesn't take up much hard disk space and it just WORKS!
I'm like a chocoholic, but for booze.
Maybe this is why for so long schools have been such strong Mac advocates. I say this from the experience of having administered networks on a pro bono basis for three separate K-12 networks. They all used Macs and in every case but one had only volunteer sysads.
I use Linux at work, and I believe that Open Source tools could take over at nonprofits and other low-operating budget environments, but in those organizations the person running the network is usually a novice who has ten times more demands than he has time or resources.
If someone could package a distro aimed squarely at novice users who simply want to create a network that will allow file sharing, Net access, and printing, with very limited options, it would spread like wildfire.
A clear, non-technical step-by-step set of instructions as a PDF (take a look at the instructions that come with an iMac - the illustrations make setup idiot-proof) is essential to success. We may be used to man files, but admins of small nonprofit networks need clear, easy to understand guides.
This is the biggest single failing of Open Source tools right now - despite many efforts, the amount of learning - "Thinking Linux" that people have to do in order to use the tools is prohibitive.
The tools are supposed to work for human beings, not the other way around. When the Open Source movement can get out of the elitist mentality, we'll really see it take off like a rocket.
Read the EFF's Fair Use FAQ
If a program team came into a project with the specific goal of satisfying 1 need, instead of 100, or 1 customer (the boss, or his daughter, or someone's niece), then you'd have much higher efficiency.
Then perhaps v2 would to rewrite the program into a framework such that it could be extended with plugins and paired with other similarly written programs.
It's a methodology that might actually work. Design for one person. Test on one person. Target one person. Support one person.
Then, afterwards, rework it so that that one person can still use it perfectly, but that everyone else on the team can still use it. Maybe stage three is to rework it so anyone else can use it, with small, minor enhancements and such, but always back to the basis that the one tester, the one user, the one customer, can still use the product.
Does this sound bad? It sounds reasonable, to me!
As for the Church Turing Thesis; a computer is a computer, but MS Word is a blender. It should not be used for maintaining address books, making flow charts, web site design, or databases. It is a blender.
It could have a plugin for web export. For address book export. For Database export, whatever. But it isn't a computer, or a system. It's just a word processing program!
Geek dating!
GPL Deconstructed
I support a lot of non-profits in my business. The average has 5 functioning computers, and 1 out of 3 has no network to speak of (Win32 peer-to-peer or sneakernet).
Why is there so much time spent on debugging, and not more on designing it? With a better overall design, you'd think that less time would be spent on bug fixing. Instead, a lot of programmers that I've noticed write a lot of hack code that's not really thought out.
About 2 years ago, I spent the 3 longest months of my life working on an exciting insurance application. (It's just about the only business-type app I've ever worked on, and reinforced my opinion that, while business problems may be quite difficult, they are not even slightly interesting - these days I only do technical and scientific programming.) The point I'm making, slowly, is that 47 days is probably actually too high. The place rolling out the exciting insurance app had a design and QC process and set of policies, but these were almost never actually applied. I would receive a tech. spec. to code from which didn't generally make sense, so I'd go back to the original analysis which also usually didn't make sense, so I'd try and locate the business analyst who had produced that (and he often didn't make much sense either). So I'd spend 80 hrs reanalysing, coding and testing something that the project manager (speaking loosely) had allowed maybe 5 hrs for. And no, I'm not a particularly slow coder, I just like my stuff to work. It's an integrity thing.
What a long, strange trip it's been.
I live in Austin TX, and I go to school at one of the schools in AISD, which is the district he is talking about. It's true: there are a lot of schools where the district's people are incompetent, and most kids there don't know how to turn a computer on, much less fix them. But at my school, LBJ HS, we actually have a club devoted to fixing computers and maintaining our network, which we call STAC. Yeah, we're a bunch of high school students, but we ARE able to keep our own network up and running. Most of us are fairly avid /. readers too. :)
I do a fair amount of C++ coding (the CS classes in high school are HORRIBLE), even at a science and math academy, and I'd say that a LOT of time is spent debugging. But it's work too. Let's see those whining end users say it isn't work when the programs they use crash because nobody did any debugging. :)
In a world without walls and fences, who needs Windows and Gates?
heh - that's *IF* you believe everything you read. and what happened to the other 1/6th??
1/4 + 1/4 = 1/2
1/3 + 1/6 = 1/2
1/2 + 1/2 = 1
What other 1/6th were you talking about?
Grabel's Law
I wouldn't agree with this. I work roughly 12 hours a day, and get maybe 2 hours a day of good, quality testing done. Then again, I work for a small startup, and am one of a very small number of coders.
:)
On the other hand, I don't have to deal with much beaurocracy
Mike Thacker
Most non-profits cannot afford to network. My company E4org, Inc. offers a linux-based network solution: email, webmail, firewall, intranet, etc. They pay monthly based on their user base. It saves them tons of $$ and lets them afford things they otherwise cannot. We have found a huge market here in D.C.
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
I can't really find any information on the site that confirms that this is grounded in hard research, like studying people working at software firms or companies.
It's sort of suspicious that the company reporting this is in the business of selling planning tools... this sounds like a great sale line: "Your current process is amazingly inefficient, but using our tools, you can streamline productivity!"
I'm not bashing planning tools or a good development process, but this number seems to be a bit sketchy.
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
The article said of the approximately 200 days a worker spends at work, 47 days are spent developing new code and the other 150 are spent fixing bugs and doing testing. This gets back to the statistics about how few lines per code a person generates a year.
What would be more interesting to learn is how many those other 150 days are broken down into design, testing, and bug fixing. Working on a large project myself I would certainly agree that not enough testing is done and the brightest aren't always the same set of people doing the design.
I'm not sure if, however, all the labor shortage could be avoided by designing things in the first place. I believe the Mythical Man Month postulates that as software projects and their teams grow in size, their complexity grows disproportionately faster. Sure it is easier to design something that is small that work just as you intended. Try throwing 40 people together each doing that with a mediocre architect and I'll tell you the results aren't pretty. Even worse are the people usually put on maintenance.
Everyone should go read the Big Ball of Mud. Really. Everyone that has ever worked on a big project will be able to relate to its contents.
-mjg