Avoiding Mistakes Can Be a Huge Mistake 268
theodp writes "No doubt many will nod knowingly as they read Paul Graham's The Other Half of 'Artists Ship', which delves into the downside of procedures developed by Big Companies to protect themselves against mistakes. Because every check you put on your programmers has a cost, Graham warns: 'And just as the greatest danger of being hard to sell to is not that you overpay but that the best suppliers won't even sell to you, the greatest danger of applying too many checks to your programmers is not that you'll make them unproductive, but that good programmers won't even want to work for you.' Sound familiar, anyone?"
Perhaps (Score:5, Interesting)
Re:Perhaps (Score:5, Insightful)
Code reviews teach the reviewers as much as they check on the author. Why would you deny the lesser programmers the joy and experience of looking at good code?
Re: (Score:3, Insightful)
Code reviews teach the reviewers as much as they check on the author. Why would you deny the lesser programmers the joy and experience of looking at good code?
I completely agree with this. Also, reviewers get to see code they may not be familiar with, and the author gets alternative views on implementation and design.
As long as everyone remains objective and professional, reviews can be very informative.
Re:Perhaps (Score:5, Funny)
Do programmers also loose karma for being fast and lose with their spelling?
Re:Perhaps (Score:4, Funny)
Do programmers also loose karma for being fast and lose with their spelling?
/irony
Re:Perhaps (Score:5, Funny)
Do programmers also loose karma for being fast and lose with their spelling?
/irony
They can be docked karma that way, but when they're not sure about something, they can cover their asses and submit anonymously. That way, if something totally whooshes over their heads, they're in the clear. They can later correct their own dumbass mistakes unanonymously and whore karma instead of losing it. What a perfect system!
Re:Perhaps (Score:5, Funny)
Do programmers also loose karma for being fast and lose with their spelling?
/irony
They can be docked karma that way, but when they're not sure about something, they can cover their asses and submit anonymously. That way, if something totally whooshes over their heads, they're in the clear. They can later correct their own dumbass mistakes unanonymously and whore karma instead of losing it. What a perfect system!
Huh. Too bad Slashdot doesn't have a system like that.
Re: (Score:2, Funny)
Do programmers also loose karma for being fast and lose with their spelling?
/irony
They can be docked karma that way, but when they're not sure about something, they can cover their asses and submit anonymously. That way, if something totally whooshes over their heads, they're in the clear. They can later correct their own dumbass mistakes unanonymously and whore karma instead of losing it. What a perfect system!
Huh. Too bad Slashdot doesn't have a system like that.
/irony
I think I'm starting to get the hang of this!
Re:Perhaps (Score:5, Funny)
wow, a Beowulf cluster of /irony
Re: loose karma (Score:4, Funny)
Yes! Free Karma... right after Willie! I'm starting a grassroots movement to save the Karma from untimely demises.
Re:Perhaps (Score:5, Funny)
/irony
/woosh
/irony
Error: Cyclic Dependency
Re: (Score:2)
Re:Perhaps (Score:5, Interesting)
That's exactly the kind of check that is harmful, according to the article. Who determines what is "excellent"? Against what benchmark? Who performs the audits? Who checks that you have spelled "lose" correctly?
Re:Perhaps (Score:4, Insightful)
To wit:
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
The benchmarks can also be defined as well. They need to be met. Make the bars well known, and what must be done to meet them.
There are great references for auditors, too. Feeling a little pain, are you? Had to throw in the grammar nazi reference?
Re:Perhaps (Score:5, Insightful)
Excellence can be determined in various ways, often through documentation, the great allergen of programmers. If you can't explain it, it isn't really done.
Suppose you have a programmer who's 10x as fast as your benchmark standard guy at producing tested, debugged code that meets requirements, but slower at writing docs. Do you make him write docs, or attach a junior programmer to him for that purpose?
Of course, somewhere up the ladder a software engineer's job becomes mostly writing docs (regardless of whether you go management or architect), but still - tying that anchor around the neck of your best dev is exactly the sort of thing Paul Graham was on about.
Re: (Score:2)
Fools trade quantity for quality. Productivity without regimen isn't cost-effective in the end run.
Re:Perhaps (Score:4, Insightful)
I don't think you're disagreeing with me. Given whatever standard of quality you wish, there is at least a 10 to 1 productivity variance in the creation of software between software professionals. Identifying developers who are on the tail end of that bell curve and removing obstacles from their path is the key to both productivity and retaining your super-programmers.
The guys on the 10x end of the spectrum aren't just more productive - they can solve problems that the ordinary coder simply cannot solve at all. If you're part of the millionth re-invention of an inventory database, this doesn't much matter, but if your business sells software that soves new problems, these guys make a huge difference.
Of course, everyone thinks they're a super-coder when they're young, just like everyone thinks they're an above-average driver, but recognizing (and retaining) real talent is supposed to be a development manager's job.
Re: (Score:2)
There's some truth to your logic. Productivity is key. Using components and techniques that enable productivity are good steps. Solving problems at the possible sacrifice of audit, scrutiny, and even safety aren't good ideas, however. I don't believe in slowing people down for bureaucracy sake. And I believe that some coders are basally more productive. Identifying them is good, but the basics of standards, QA checks, review, and audit are still necessary, and perhaps even mandated by law.
We all want the be
Re:Perhaps (Score:5, Interesting)
My fundamental point is not that documenation and paperwork should be avoided, but that in some cases it's just a stupid allocation of resoruces to have certain developers do that work. In the old days, IBM would pair a tech writer with *every* programer, so that really good docs could be produced with a minimum of distraction to the coding. It's hard to know whether that produced the best code (though there's a lot to be proud of in 70s mainframe code), but it produced lots of *really* good documentation.
Better to make a video (Score:2)
A lot of people who are bored stiff with writing documentation are good with white-boards and q&a sessions.
Make a video of the dev explaining the whys and wherefores (stuff that usually gets omitted anyway - youknow - "wtf did they do it like THAT?"), explaining how it's to be used/deployed, and answering questions from the other coders/reviewers/testers.
Re: (Score:2)
Wrong. Once the program is written, it has been explained in detail to the party which will be executing it. Namely, the machine.
If you want to determine the excellence of a program, you have to examine the program -- if not the code, then its behavior. The documentation tells you little. If you just want a check box for your corporate "excellence" p
Re: (Score:3, Insightful)
We would disagree.
Unless a code set is monolithic, it has to interact with other components. Maintenance and audit mandates basic documentation. Those that eschew it aren't really programmers, because that's part of the job. Instead, they're really good artists, creative people, and not industrial professionals that understand they're part of a larger process. Part of the lone wolf contingent of coders and hackers will always refuse to be a part of the discipline required to work and play well with others.
Re: (Score:3, Interesting)
to wish I had mod points...
I really like igw's post http://developers.slashdot.org/comments.pl?sid=1047369&cid=25954607 [slashdot.org] about attaching a tech writer to a dev. While it may play to the primadonna set (in a bad way) there is some sense in getting those lone wolf types, especially when they have the combination of difficult to teach skills and the unteachable knack of genius for a particular type of problem you may have. I (senior tech) have been attached to such an engineer (hardware dev) who was simpl
Re:Perhaps (Score:4, Insightful)
Documentation may be necessary; certainly documenting interfaces is, and some amount of internals documentation is prudent. But no amount of documentation will make poor code anything but poor. Nor will any lack of documentation make excellent code poor; it merely makes it undocumented.
Courageous submission... wasn't that one of the Ingsoc slogans?
Re:Perhaps (Score:4, Insightful)
Benchmarking is exactly were the problem lies....
Having your code reviewed by a peer who can actually comment on it and understand what you are (or are not) doing is not bad. Either they understand it, or you have to defend your work with actual technical arguments. The end result is that you both have an opportunity to learn.
Having your code reviewed by a mindless idiot comparing it to the official procedure is bad.... Even worse when the idiot is replaced by a program. Forcing everybody to follow a single holy procedure simply reduces all code to be mediocre.
Re: (Score:3, Insightful)
The best judge of good code is always other programmers. I also think that once you move into management for a few years, you start to lose the ability to tell good code, because there really is an element of the "best application of current technology" somewhere in there.
The worst place to work would be a place where nobody ever looked at or judged your code. That's like an author with no audience.
Re:Perhaps (Score:5, Interesting)
How do you identify "good code"? That's one of the great problems we have as software developers. Quantifying 'good' code is extraordinarily difficult. Code reviews do an excellent job of identifying clever code, but rarely capture the full utility of what is being written. You may think you know good code when you see it, but over the course of my career I've become convinced that is not true at all.
Really the problem is that the only way to truly measure code quality is by seeing how it runs in a production environment. Even then I can easily quantify the quality of the teams overall output (does it work? does it work consistently?), but tracing that back to an individual programmer is often nearly impossible. Systems tend to interact with each other, and placing blame is not an exact science. The gulf between 'good' and 'good enough' is not nearly as wide as it seemed when I was a novice programmer.
Great code almost never breaks. Good code works most of the time. Poor code is another matter.
Poor code is easy to spot. Poor code never works. It's ugly. It's complex. It's stateful. It's jump off of the screen and practically begs to be put out of its misery.
That's precisely why companies have processes and checks. They are an attempt to catch marginal code and make it 'good enough'. The problem, as the article points out, is that in the process they often inspire great coders to deliver marginal code themselves.
The secret is to spot (through some mixture of science and art) great programmers and provide them with the freedom to write great code. If circumstance requires you to hire marginal programmers, then by all means put the process in place to make sure that what they do doesn't detract from the work your best and brightest are doing. Separate them as best you can. Limit how their systems interact.
But whatever you do... don't limit your best programmers, as they are far more valuable than hundreds of poor ones.
Re: (Score:3, Funny)
The "robustness" test isn't good enough either. Sometimes poor implementations of good ideas spurn enough innovation and demand that its marginal quality is irrelevant. The early web browsers, email programs, etc.. were likely neither robust or well implemented. On the other hand, some solid, robust good implementations of ideas are so intractable, that at best they merely serve the original purpose, and at worst are like an albatross around the necks of future developers ( usb anybody ?).
David Parna
Re: (Score:2)
Sometimes poor implementations of good ideas spurn enough innovation and demand that its marginal quality is irrelevant.
Just because something is valuable in spurring innovation doesn't make it good code.
Re: (Score:3, Insightful)
Real Talent? (Score:2)
Perhaps there is no "real talent" to use. Seriously, just because there are programmers out there who think they are better than most of the others, doesn't make it true.
Of course, if programmers who post on Slashdot were representative, we must all think we are über-programmers.
Re: (Score:3, Informative)
No, there really are programmers who are 10x as productive as "normal", and of course programmers who contribute negatively. You'll know either extreme when you work with one.
Boss: we've had a team of 5 on this problem for a couple months now, and they're way behind - could you take a look?
Dev: sure, give me a couple of weeks.
Two weeks later.
Boss: so, can how's that project going?
Dev: oh, I'm done.
Boss: Done? Great - what was your analysis; how can we speed things up?
Dev: No, no, I'm done with the project. The approach that team had was crap, so I just did it right. I'm running my unit test now, but it looks good so far.
Boss: -speechless-
You may not believe it until you work with someone like that, but they're out there (and large companies do a terrible job of retaining them - as Paul Graham suggests, the main thing devs like that want is to not have obstacles to their productivity).
Re: (Score:2)
"No, there really are programmers who are 10x as productive as "normal", and of course programmers who contribute negatively. You'll know either extreme when you work with one."
This is the most common programming myth of our time. We don't have any comprehensive definition of what "productive" means when applied to programming yet we know that some are 10x better at it. Or is it 30x? Or 100x? I've heard all of these figures claimed with no real proof.
Why when it comes to methodologies and productivity we dr
Re: (Score:3, Informative)
I know what "productive" means. Knowing that is part of my job. "Productive" is delivering features in a maintainable, supportable way, per unit time. Sizing features and defining "maintainable" and "supportable" in terms of concrete rules and best practices is a large part of the skillset of a very senior engineer. Finding the hyper-productive programmers and twisting management's arm to retain them at all costs is another.
Again, the 10x developer sounds like a myth until you work with him -- I'd say i
Re: (Score:3, Insightful)
If 3x developers are common, then what is the baseline you are comparing them against ? The very worst programmers ?
So, since the baseline seems to be less than zero, and the best developers are three times that, are you trying to say that the
Re: (Score:3, Insightful)
"Common" as in: "you've probably met one". When you can't measure something well, you can still measure it a little - a half order of magnitude isn't exactly overspecifying. However, when when you know you can give a team of 5 engineers N days, or your good programmer N days, and get the feature delivered on time, that's a pretty good basis for comparison!
There are plenty of software development jobs (even outside of life safety) where there's no room for serious errors. Sure, GUIs can be poorly designed
Re: (Score:3, Insightful)
"You can engineer maintainability. You won't know how successful that effort was until after the maintenance is performed."
You can certainly try your best, but as you say, you only find out later how you did. But getting back to the main argument, programming "goodness" is a multidimensional quality that often can't be fully measured until some time has passed.
There is rarely any attempt to measure it in the real world beyond the misleading metric of LOC/time.
Re: (Score:3, Interesting)
Maintainability damn well can be designed in from the beginning!
I agree, it most certainly can. Seriously, what is the point of a clean, well-engineered design, if you're not attempting to build a solid foundation for future work? Why not just crank it out any old way so long as the spec is met? Rhetorical question.
Learning how to code for maintainability up front is more a matter of experience (having been burned enough times by not having done it, and tried enough possible solutions until you've found those that work) that it is talent. It's also something that man
Re: (Score:2)
What's your contention, that there's no such thing as skill or ability and anyone who's been sufficiently trained to perform a task is equally good at it? If so, that's obviously bullshit.
Re: (Score:3, Insightful)
Re:Perhaps (Score:4, Interesting)
I don't think you even need "good code". I worked on a project that eventually failed and all the code we looked at in those reviews was "good". Either that or we made it good. The big problem was that it did the wrong things.
The problem is not with the people who write the code. Most are OK and reviews catch gross errors but in out case we had some basic "big picture" ideas wrong.
Microsoft Vista is a good example of this. Likely the code would pass a review and has few mistakes but the problem is the dumb ideas that got written into the specifications.
It's like the "bridge to nowhere" problem. Good, competent structural engineers build something no one wants or needs.
Re: (Score:3, Insightful)
The problem is that what you are describing is nothing at all like what the market actually wants. The market actually wants massive feature lists delivered as fast as possible, and their level of caring for whether or not quality is there is very low. This is very unlike, say, a bridge, where the primary public concern is going to be that the bridge not fail and kill them. Or an electrical product where the primary public concern is that it not short out and start a fire that kills them.
When things go w
Re: (Score:2)
While agreeing with you, I'd summarize it thusly: good code is easy to maintain. Great code is easy to support in the field.
The importance of good logging cannot be overstated, nor the importance of programmer-developed unit tests run before any check-in.
In the code itself, I'd add: good code minimizes dependencies, minimizes internal assumptions (design dependencies), and doesn't abstract or optimize at the cost of simplicity and clarity (the last is very hard for many devs to grasp). As Knuth said: prem
Re:Perhaps (Score:5, Insightful)
Perhaps programmers that have consistently good code should have some value placed on them. We'll call it "Karma". Programmers with good Karma get audited less often than others. If they fail an audit, they loose some "Karma" and have to write a bunch of excellent code to get it back.
That's awful in so many ways.
For starters look at how poorly Karma works here. It serves to re-enforce awful sheep mentality. Just try putting down Google, Apple or Linux. Or try praising Microsoft.
Next what you're proposing creates a negative feedback loop. A developer codes well and gets through a few audits. Now they're trusted, they can afford to let things slip for some time before anything is caught. There's less incentive to keep producing good code, and there's more of a chance that an error will slip through. No one is perfect and mistakes will happen. The way to protect against them is to ensure there's some redundancy, and taht is exactly what a code review provides.
Also consider retention rates and the average time a developer spends at a company. Does an expert or lead programmer start off having every little thing reviewed? Who's qualified to do that? Or are they trusted based on heresay and a resume? If so how long will it take to find a dud programmer?
Next consider what effect it will have on the morale of a struggling programmer, or one that doesn't cope well with reviews. Especially a junior one whose abilities can be salvaged. A co-operative might work, but constantly giving more and more high pressure code reviews is just about guaranteed to break such an individual.
Finally, you should realize that such "karma" already exists informally and that making it a more formal process achieves very little. In other words developers very quickly get a feel for what the strengths and weaknesses of another developer are.
Re:Perhaps (Score:5, Funny)
Google is evil incarnated, Apple is style-over-function overpriced junk, and "The Year of The Linux Desktop" ain't coming soon.
Microsoft, on the other hand, has some really funny employees [youtube.com] (and Reversi).
/em ducks
Re: (Score:2, Insightful)
Re: (Score:2)
(mount soapbox) Having every little thing reviewed is a necessity, not a problem. Expert and lead programmers need to set the example by getting reviews. Always. The tiniest change has the potential for causing chaos. Teaching by example is just as important as producing. (dismount soapbox)
I once spent one full week debugging to find a bug when someone made a code change that was unnecessary, trivial, not reviewed, and wrong. (Someone thought that if (! p) looked better than if (p != NULL). Which one looks better is debatable, but one is the opposite of the other).
Re:Perhaps (Score:5, Interesting)
We have a more informal system where I work. Whenever anybody checks in some code, whoever wants to automatically gets an email to notify them (for example, I am set up to receive notifications for any changes in a few directories where I do most of my work). Anybody who wants to then reviews the change. If there is nothing to comment on, it's completely transparent, and the person who checked in the changes is not even aware that they got reviewed. If there IS something to comment on, most likely someone will talk to the original coder (or send them an email), saying something to the effect of "by the way, did you consider such-and-such?", or maybe even "good idea!"
The system keeps track of who reviewed what change. As a check on the process, if there is any change that has been in the system for x days but has not been reviewed by at least m developers and n testers, the original coder gets an automatic email saying "please arrange for someone to review your code."
This is, of course, in addition to the automatic emails that get sent if a change actually BREAKS something. Those get dealt with right away.
So the review process does no harm to anybody's morale, except in the cases where that person really is producing bad code.
Strangely enough, it seems to work quite well.
As for your other point, about "A developer codes well and gets through a few audits. Now they're trusted, they can afford to let things slip for some time before anything is caught. There's less incentive to keep producing good code": I don't want anybody with that attitude in my group, period. I am not in any kind of supervisory position, but if there is someone on the team who only produces good code because of some "incentive", and the team lead doesn't do anything about that, then I don't want to work for that team lead, either. I will vote with my feet, and I don't think I would be the only one. And then this would become, no doubt, a much more "normal" software department, instead of an amazing one.
Re: (Score:2)
ISTM that the "karma" system should be turned upside down. Those that produce quality code should have it lauded to the group at large. There should be great publicity surrounding the good code. Maybe have the team (and management? don't know) vote up the best code so that everyone knows about it. The reward is having your code announced as the best code of the week/library/project/whatever. Those who don't produce good code are motivated to do better so that they get the praise too...
Thus those top coders
Re: (Score:2)
Interesting idea..
There's a (probably apocryphal) story about the US car manufacturing industry. When some Japanese companies decided to build over here the company execs wanted to make sure that the same level of quality from the Japanese plants were retained in the USA. To that goal they implemented a bunch of newer controls and QA methods. The result was that the USA factories ended up putting out better cars than the Japanese factories. The controls were then put in place across the entire company.
Code
A fine balance (Score:5, Insightful)
It's like anything else in life. The sins of one hurt everyone.
There will always be people who get shampoo in their eyes, and because of that these checks will always exist.
Re: (Score:2)
At a small company, it's frequently possible to find those people and stop them from writing any more code.
A better idea ... (Score:2)
I'd be willing to put up with more checks provided that there are checks put on:
It's official (Score:3, Funny)
From TFA: "Programmers are unlike many types of workers in that the best ones actually prefer to work hard."
Thanks for telling me I suck, Paul. Now excuse me while I loaf.
More checks! (Score:5, Insightful)
From the article:
So bureaucracy has a cost in that it places lots of checks on things, and the solution to that is adding more checks?
Sounds like solid bureaucracy to me!
Re: (Score:2)
Re: (Score:2)
From the article:
So bureaucracy has a cost in that it places lots of checks on things, and the solution to that is adding more checks?
Sounds like solid bureaucracy to me!
Building a check on your production line is very expensive. It automatically slows down the line. It comes with the overhead of modifying the production line, re-instructing the people on the line, etc. Building a check on the "verification process" is far less expensive. Management is already just overhead, increasing their overhead to protect productivity is way cheaper than the alternative.
Re: (Score:2)
Building a check on your production line is very expensive. It automatically slows down the line. It comes with the overhead of modifying the production line, re-instructing the people on the line, etc.
And yet, Toyota does just that [toyotageorgetown.com]. But why are you talking about production lines in the context of software?
Re: (Score:2, Insightful)
The bureaucracy is expanding, to meet the needs of the expanding bureaucracy.
I have mixed feelings. (Score:2, Insightful)
At big companies, software has to go through various approvals before it can be launched. And the cost of doing this can be enormousâ"in fact, discontinuous. I was talking recently to a group of three programmers whose startup had been acquired a few years before by a big company. When they'd been independent, they could release changes instantly. Now, they said, the absolute fastest they could get code released on the production servers was two weeks.
At the big company I worked at, someone added some features to code that I wrote. It broke my code. I wanted to go in and fix it. Why not? I knew how it worked. I couldn't without a defect written by a tester.
On the other hand, if it was reviewed, the feature wouldn't have gone in; at least not without my input - I would hope.
Re:I have mixed feelings. (Score:5, Funny)
Annoying, but easy to handle. Testers love to find bugs, whether it be for the joy of crushing a young programmer's spirit, or for the look of fear in the eyes of the product manager as the release date approaches. Point a tester towards the bug, and he'll go right ahead and write a defect, possibly cackling evilly as he does so.
Death March (Score:5, Insightful)
I find the premise of the essay wrong. Go read "Death March" by Ed Yourdon (http://www.yourdonreport.com/). Most of the time problems aren't processes - they're people.
"Programmers, though, like it better when they write more code. Or more precisely, when they release more code. Programmers like to make a difference. Good ones, anyway."
This is a red flag. Coders that just code are part of the problem of a death March. Who has worked with wunderkind that churns out 16 hours of useless bug ridden code? That refuses to write unit tests because they slow him down? And at the end of the project look back, the MetricsReloaded tells you "Yes, that developer wrote the most code, but it is also the most defective and has the least coverage?"
Good processes are adaptive. Good people are agile. You can't build skyscrapers on spec. I am so annoyed by people that push a methodology or ideology that cannot also cite the specific historical evolution of software processes.
Re: (Score:2)
Re: (Score:2)
If you have a bad coder fire them don't hamper everyone with a bad process so idiot's can become mildly productive.
If a person fires every bad coder working for him, soon enough he'll be the only one left to work on code. If the company is sufficiently large, maybe he'll be lucky and have a handful of coders whose skills could probably be utilized better if they had bad coders to pass on tasks to (and who hopefully can eventually become good coders.)
Dunno, I'm in my 4th year of computer engineering and what I see is that most students are somewhere between mediocre and horrible programmers. I assume weeding has made the
Re: (Score:2)
PS: Look at the development history of Mac OS X to see what can happen when you remove useless people.
Re: (Score:3, Insightful)
How much does it cost to find, vet and hire a replacement coder? Both in real money terms and in loss of productivity. How does it compare to bringing the 'bad coder' up to speed through better training strategies?
Just some thoughts,
skribe
Re: (Score:3, Insightful)
A good coder should enjoy their work enough that they can help bring others up to speed. Everyone benefits. The good coders benefit from better communications with their co-workers, as well as knowing what can and can't be handed off to others, and how much supervision they'll need.
Projects don't fail because of bad coders. They fail because of mismanagement, poor resource allocation (the biggest problem being time constraints), lousy communications, lack of trust, and a willingness to take shortcusts
Re: (Score:2, Informative)
if you use metrics to understand how hard someone is working, then you fail before you have begun.
metrics == management
Re: (Score:3, Interesting)
And some of us like to program just for the sake of programming. And create applications and solve problems because to do so is interesting and fun, and one gets to work with other smart people.
Re: (Score:3, Insightful)
Programmers, though, like it better when they write more code.
I clearly prefer to write less. Noting better than cleaning up code and ending up with deleting a third of it while making it work better than before.
...Perhaps the author is a little biased? (Score:3, Insightful)
Anyone else pick up on this -
Programmers are unlike many types of workers in that the best ones actually prefer to work hard. This doesn't seem to be the case in most types of work. When I worked in fast food, we didn't prefer the busy times. And when I used to mow lawns, I definitely didn't prefer it when the grass was long after a week of rain.
Just because YOU didn't like being busy at your other jobs doesn't mean everyone else in the world feels the same way. I worked in fast food and when I did, I liked it a lot better when it was busy. A 10 hour shift flies by when you're making orders non-stop, but once closing time came and it was time to clean up time seemed to stand still. I was still working but the work I was doing was so mundane and slow paced (mopping floors or washing the nights dishes) that it seemed to take forever.
There's also the possibility that you're a hobby programmer and not a career programmer. You might like programming outside of work, but there are people that wrote code just because it'll pay the bills. Those people generally like writing code as much as you liked mowing long grass.
Re: (Score:2)
Yeah, his examples are pretty stupid too. Comparing writing commercial software vs. cutting yards? One's a career and the other's a way for a high school kid to make money over the summer.
That's not to say that there aren't professional landscapers who take their work seriously, or that there aren't programmers that aren't lazy beyond words. Take any job position, heck take almost any individual company, and you'll probably find a handful of relatively lazy and unmotivated people, and a handful of super-mot
Re: (Score:2)
Having done a few jobs in my time, I can testify programming is among the easier jobs I have done - in terms of getting through the day. Sure, sometimes it is incredibly frustrating, but sitting at a desk, listening to music and coding is for the most part, great.
(Especially when you're not debugging).
Re: (Score:2)
Amen, brother. I pretty much don't care what I'm doing - as long as I'm engaged, and can't think about the drudgery. Ennui kills me.
Re: (Score:2)
... there are people that wrote code just because it'll pay the bills. Those people generally like writing code as much as you liked mowing long grass.
Those people should find a different line of work that they DO enjoy.
Re: (Score:2)
And there are several other jobs that I also feel very strongly should NEVER be done by someone who is only doing it for the money. A religious minister, for example.
Or a girlfriend :-)
I'd like to include teaching as something that should only be done by those who are passionate about it, but I can see that there would be practical problems with this. And yet, a good teacher can change a kid's life. I had several great math teachers, and that's how I ended up in this field. I've heard of great English t
Re: (Score:2)
To me, it's weird that you would separate programmers who enjoy doing the job away from career programmers. In my experience, it's most professional programmers, and certainly the best ones I've worked with love doing it. But biased towards programmers who enjoy programmers? Hell yes, it's an article talking about tech startups, of course it's going to make some assumptions about programmers in the audience.
obviously (Score:2, Insightful)
Re: (Score:2, Insightful)
Now that I've I know, I'm going to dismantle all my QA procedures and hire the sloppiest programmers I can find!
How about I take every little thing you say and take it to the farthest possible extreme without any regard for the subtleties in what you originally said?
What you said sounds like a great idea! Why don't we KILL ALL THE PEOPLE WHO DO QA, like you are clearly suggesting, rape and torture their families and then hire pedophiles and trained gorillas to do the work?! Isn't that exactly what you wer
Cyber "security" is in the same boat. (Score:2)
Where I work, the Network Nazis have made our computing environment so secure from cyber-threats that we might as well just unplug our CAT-5 cables altogether.
Re: (Score:2)
You can LART or hang a lot of Nazis with cat-5.
Unplug, and become a BOFH!
Agreed, Too Much Oversight Kills (Score:5, Interesting)
My group is a prime example. We all worked for a startup that generally released a new version of our application about 3 times per year. Over a few years we had developed a nice lean development process that involved documenting our design, but only in enough detail to be able to fairly accurately estimate the development effort (in X days, X weeks, or X months).
Based on the estimates, the biz dev group would then pick and choose features to make up 3 months dev + test time.
This worked great, and we pretty much never had a late shipment and few bugs.
Then we got acquired by a giant 3-letter company with huge amounts of development process and tons and tons of "standards", and immediately were ordered to begin a 16 month release consisting of removing all open source and complying with standards. All their architects routinely veto our decisions and our design documents must be very very detailed and approved via heavyweight process before implementation can begin. 24 months later we're still in development, only recently the last design document was finally approved; at the moment it seems we'll be about 12 months late in total.
Now they're asking us why we have so many tests planned, and making us remove half of them. Supposedly quality is a major priority, but they have no testing group; only people to enforce standards. All tests and test cases are written and implemented by the developers themselves.
Dont even get me started about the outsourcing issues.
Re: (Score:2, Informative)
Forgot to mention, morale is in the toilet, because after 2 years of effort we're about to release a new, fully standard-compliant version of the application with -0- new features, and even less compatibility with external applications than before.
Most people here have told me the only reason they have not left is because we'd never be able to get the same money or even half the vacation elsewhere.
Re: (Score:2)
If you're talking about HAL...
I fired them because they weren't paying me what I was worth to them. I'm getting paid more now (but the benefits are less, so it probably balances out).
I did get to write a lot of code that skipped as much of the process as I could (mostly the parts outside my group; it still went through design and code reviews). I was one of those guys making constant, iterative improvements in the guts of my component, that had no "business justification" because the only thing it made be
Don't forget opportunities to redo stuff (Score:3, Insightful)
The time for that was what I missed on my last job. While there was not much oversight of how we actually wrote our code, deadline pressure always created a feeling of "you cannot afford t
Re: (Score:2)
that is the difference everybody keeps trying to put a finger on. It's the artist that wants the code to be "right" for it's own sake... the businessmen just want it done so they can sell it.
Re: (Score:2)
Piss poor reason for staying around. remember the highest paid do nothings for a company get laid off first.
Re: (Score:3, Insightful)
Exactly, what made your company interesting and worth buying was what you DELIVERED! At this point you've missed 8 "releases" spending the entire time essentially rebuilding and re-documenting according to "old and slow" rules. Because of the overwhelming paperwork, your division is now a "loss".
While you needed more structure, your new owners sacrificed ALL your productivity for writing reports!!! They made no money from buying you.. worst is that your employees probably lost the creativity that make the
Re: (Score:2)
But, but ... they're a big company, they MUST know how to do things. After all, a big company never fails, but a lot of small ones do.
As a programmer I want to avoid mistakes... (Score:5, Insightful)
What I don't want is:
- To be reprimanded for every little mistake I make, or worse be put in a position where a little mistake on my part can cause a huge, expensive and/or very visible problem
- To be forced to comply with procedures that do not in fact improve quality but do require 90% of my time leaving me with 10% time to program
- To have no creative input into my code.
There are good ways to achieve similar goals without the above antics. Continuous integration comes to mind. Well qualified specialist testers for User Acceptance is good too. Avoiding mistakes in a way that is programmer friendly will actually improve morale and an employer more desirable. The trouble is that too many employers try to equate software manufacture with mass production factory work in every way and treat their programmers accordingly. If you look at the kind of work a programmer enjoys vs the kind a factory worker is expected to do, no wonder they leave or won't join.
Nothing changes. Really. (Score:5, Interesting)
This keeps coming up in various shapes and forms but the fact of the matter is that brilliant, high producers aggregate in places; and so do idiots.
Tom DeMarco ran a study of this in the 80s wherein teams were asked to solve the same problem. He expected a scatter-plot. It was a 45 degree line between the people who knocked the problem off and those who were clueless.
What didn't matter:
Platform. Language (except assembler, those folks were _lost_.) Operating System.
What did matter:
Team coherence and capability.
Design and planning; raw ability to design and plan as a coherent team. And not just a bunch of losers following a Pythonesque "Book of Common Knowledge."
(I have been to many "Does the witch weigh less than wood" meetings...)
Look at the back cover of Boehm's "Software Engineering Economics." What he _measured_ was that team capability overarchs everything. Period.
I would also ask you to look at the surface exposure of development. Folks who develop on the shoulders of many giants can and should be trying lots of stuff, because that's why platforms are built.
Folks working closer to the core (the OS, drivers, fundamental code) don't change as quickly, nor should they.
I've worked as a hatmaker (sheer, unbridled creativity with fancy ribbons and flowers and such) for high-end ladies and I've sat, confounded by bad documentation for UARTS.
Two different regimes.
Been there, agree with that (Score:4, Interesting)
This story hits very close to home for myself -- I've sold two companies to larger companies where they commercialized my software. When you're a scrappy startup, you ship instantly. When you get incorporated into a larger organization, you don't ship instantly, which hurts because your intrinsic motivation (for the A-listers and entrepreneurs anyway) is shipping.
One shocking thing in the article for me is just how much people would give up in order to ship faster -- startups that got acquired would give up some of the acquisition money in order to ship faster in the new company. It's probably a limited sample, but I know I've felt that way. This is a large portion of what I call "suck" -- things that slow down shipping. I'm not anti-QA, but after a particular point all you did was slow down shipping.
One satisfying aspect of the work I did at the last acquiring company is that every time I checked in code, I knew I could with a straight face recommend that we ship it. I mean, it wasn't a full QA pass, but it was code with a supporting set of automated unit tests incorporated into a system designed as an extensible framework. Any negative impact would be isolated to that specific functionality (high cohesion, low coupling). A small group of internal power users and my own server would take the daily builds and give feedback as to how it felt in production and report any major issues.
The message here seems to be "if you can optimize the process in some way, optimize it so you ship faster". And in the meantime, go ahead and pretend like you're shipping every day (a complete, ready-to-go, high quality build). You'll be surprised how much better you feel even with that.
Re: (Score:2)
Well, I was going to post something similar, but you put it in much better words than I could have!
Mistakes can mean breakthroughs (Score:3, Insightful)
I don't care who wrote the article (Score:3, Funny)
This sort of thinking does not justify the new userpage.
PHB Solution (Score:2)
... but that good programmers won't even want to work for you.
Fine. Then we'll hire twice as many bad programmers and pay them half as much.
The appropriate question (Score:2)
The appropriate question to ask is would a thorough code review of the Mars Climate Orbiter [wikipedia.org] software have prevented its loss? The problem was one of units (metric vs. English) which means the code on either side of the interface was absolutely correct. Only a live person looking at both pieces of code could realize that one piece of code used metric units while the other used English units.
Likewise, the code on either side of the interface may have been a paragon of software virtue. The "quality" of th
Processes galore (Score:3, Informative)
In my previous job, I worked for a huge manufacturing company. I developed, maintained and supported an add-on (plug-in, extension, module, whatever) for their 3D CAD/solid modeling application (Pro/Engineer).
When I first hired on, and started working with the application, I learned about the quality process we used: SPQA, or software process quality assurance. This was relatively straightforward, and, in my opinion, didn't add too much overhead. It was basically a checklist of things that a manager went over with the development group. Then we added AQA, application quality assurance. Not only did this add more overhead, but some of the requirements of the two processes conflicted!
The projects my group worked on were fun, cool, and cutting edge, and the majority of the staff was quite engaged in their work. So we worked through all this process nonsense, and basically got used to it. However, lurking in the background all the while was 6 Sigma. The company had adopted this methodology wholesale, and was forcing it to be used in every facet of operation. Now, not only did we have our previous processes, SPQA and AQA, but we had 6 Sigma to contend with.
Looking back, it's sad how much time and effort was wasted just trying to figure out how to integrate all these processes into our development. Literally, the whole section (about 12--15 people) spent many meetings and countless hours coming up with process maps, just to explain how our development would proceed, and comply with AQA, SPQA, 6 Sigma and anything else management felt like we needed to do. I used to eat lunch with the supervisor of another group---he had actually worked in the same group as me, years ago. I'd be moaning about how much of my effort was spent just trying to juggle all these processes, and he'd say, "Back in my day, we just thought up an idea and coded it." I'd talk about the growing queue of bugfixes and enhancements, and how none of them could ever be realized without eliminating all this process nonsense (or doubling the staff and budget) and he'd smile and say, "I remember when so-and-so called me up, asking if I could make the program do such-and-such, and I did it the same afternoon!" Sigh.
Re: (Score:2)
Re: (Score:2)
"One often meets his destiny on the road he takes to avoid it. [imdb.com]"