The Digg Crew wants to hear your thoughts!
Please take our short survey about Digg and potential feature ideas.
Does process matter?
128.ibm.com — The value of following an agreed-upon process in software development is well-established. But what sort of process? How complex? For what size teams? Professor Gary Pollice answers these questions by considering the variety of process needs within an enterprise
3monkeys- 374 diggs
- digg it
- jayripley123, on 10/12/2007, -18/+2Mark as lame!
- becominglumberg, on 10/12/2007, -2/+13You are right. IBM surely doesn't know anything about computers...
- nicepants, on 10/12/2007, -1/+25Here's a process idea...
How about the boss doesn't come by my desk 3/4 of the way through a project asking about features that were never-before requested, and still expects it to be done in the same amount of time.- mrfoos, on 10/12/2007, -2/+6I'm with you brother.
The thing to keep in mind is that when managers, architects and "intellectual" developers talk about process, what they're really talking about is CYA (Cover Your Ass) policy. They need to make sure, at the cost of everything else including success of the project, that they don't get blame for any failures. As the "process" grows and grows and grows the risk weight of blame per individual involved gets lighter and lighter and lighter.
If software development process was really about success of the project the cogs would better spend their spin cycles on their hiring and training / mentorship processes.
Good people will succeed regardless of process. - elroy, on 10/12/2007, -0/+8Ahh, there's a word you need to familiarize yourself with: "No."
Honestly, you'll seem a lot more professional if you use it in cases of scope creep.
- mrfoos, on 10/12/2007, -2/+6I'm with you brother.
- dcoolidge, on 10/12/2007, -0/+4scrum
- JJBagoose, on 10/12/2007, -1/+8Process is very important and the earlier a developer realizes it the better off they will be.
- roqs, on 10/12/2007, -0/+3on an enterprise project, when the ***** hits the fan, quality of process is most likely to suffer.. system testing becomes unit testing.. user acceptance testing becomes system testing.. etc etc..
in my personal experience, investing in more time and resources are a rarity..- williamdyer, on 10/12/2007, -1/+1Right you are, because the process keep telling management they are full of *****, and we can't have that.
- KevinJ, on 10/12/2007, -0/+8Extreme Programming FTW!
http://en.wikipedia.org/wiki/Extreme_programming- quine, on 10/12/2007, -0/+5FTA
"What disturbs me, and one of the reasons I don't "teach Agile," is that people tend to develop a narrow view of the world when you give them just one approach. They tend to see only as far as their current environment allows." - deabyss, on 10/12/2007, -3/+1A process that failed on its debut.
Extreme Programming is good for rinky dinky applications where all you do is turn Celsius to Faranheit and vice versa, but it will not do for large scale solutions. - blueroo, on 10/12/2007, -1/+4Fascinating, deabyss. Completely and utterly retarded and wrong, but fascinating.
So how do you explain the hundreds of non-trivial projects I've seen numerous companies perform with agile techniques? Millions of lines of code. Thousands of components. Gee-wizz, that sure is a wonder.
What exactly about EP fails, in your opinion? Which techniques? - deabyss, on 10/12/2007, -1/+2I did not bash Agile methods. I am bashing specifically EP. It didn't work when it was first introduced in the Chrysler project, and it continues to fail on any project of significant size.
If you are creating a web site of limited functionality or creating a software package that does not have too many moving pieces, then EP will do. But don't expect those projects to stand the test of time; something that more formal software life cycle processes will always take into account.
I myself have implemented an agile method. But don't confuse this with the utter nonsense that is EP.
What do I think fails? Well in all other engineering disciplines, a formal design before starting is a requirement. Software Engineering is no different, if you disagree then I don't think you have worked on a large enough project or one that needed to scale beyond five years or five servers (or both).
Pair programming is a silly concept, I will leave this to others here to respond to that. In short, it forces your excellent programmers to work at a slower pace. And 100 man hours won't go as far either.
And the biggest pet peeve I have about it. You get the most out of EP when your workers have a very limited domain knowledge. If you build accounting systems, EP will reach its theoretical perfection when the workers have been working with accounting systems for 20 years. Your first accounting system is more of a learning experience as requirements are gathered as you code. Your collection of index cards with stories starts to get bigger over time. Your pre-built components (from past projects) grow. Guess what, if you were to have started out with a big-design-up-front you would have designed those components ahead of time. Your domain knowledge would be preconceived (and you would hire based on this).
EP has very limited applicability. And I personally would restrict it to the hobbyist or school projects. Keep it away from the enterprise! - KevinJ, on 10/12/2007, -0/+2Ive never EPd, I just thought the named sounded funny.
Although seems like a good way to build synergy in a CompSci class - Scarblac, on 10/12/2007, -0/+3@deabyss: remember, _there is no silver bullet_.
No process will work for every type of project. None. Ever.
So XP is good for some projects, not for others. For the projects for which it fits (not too large, constantly changing requirements, a lot of contact with a customer, fit for incremental deliveries) it works quite well, _if implemented correctly_.
Just learn to recognize for which types of project it is good and add it to the toolbox, don't claim it's bad because there are projects for which it won't work, because that's besides the point.
- quine, on 10/12/2007, -0/+5FTA
- Almadiel, on 10/12/2007, -0/+4It is my experience that neglecting the processes is usually much more costly than following it, at least loosly.
- buildmaster, on 10/12/2007, -0/+3Agile is never about no process, a fact that some people miss, it's about having only the most streamlined and lightweight processes to suit you... if you have a process that no one does, what is the point of the process?
Less hard and fast, more retrospective...
oh that's what everyone forgets to do... look back and say how well did i do? how could we have done it better? what worked? what didn't work? and change things accordingly. - Urusai, on 10/12/2007, -1/+2Process is what you have when you forget what you are doing and why you are doing it, you just do it because otherwise your paycheck will stop.
- ajs05, on 10/12/2007, -0/+4fta
"Developers need to realize that if the company is profitable, these people at the top must be doing something right. There are too many profitable companies for things to be working in spite of poor leadership!"
This logic is hopelessly flawed. There's often serious time-lag between product development and revenue/profit. There's often management turnover too! And who says a transiently profitable company is doing it right -- maybe they cooked the books.
In my experience, an overwhelming majority of those in management do not have a clue what processes are appropriate for their organizations. Some don't even appreciate the concept of a defined process. Others just want to force their organization to achieve a meaningless milestone such as CMM Level 3 or 5, thinking that is an end to itself instead of a means to an end of improved product quality.
-- ajs (certified scrummaster since 2004) - josegutz, on 10/12/2007, -2/+2Does process matter?
I don't know... Ask a woman...I am fine with mine... Oh wait.. - AtticusFinch987, on 10/12/2007, -0/+2Didn't someone named Fred Brooks once say something about the nonexistence of Silver Bullets in software development processes?
- daltonlp, on 10/12/2007, -1/+1http://www.fighttheprocess.com
- ellenweber, on 10/12/2007, -0/+2While I agree that process does matter -- it would be good to see even more negotiation in the designs for that process. It concerns that that we are taking so many creative people and expecting them to mold their own approaches or processes into one that one or two people designed to fit their preferred approach. Great post and thanks for the opportunity to look at several angles on a key topic.
Brain Based Business - beotch, on 10/12/2007, -1/+0Linux developers seem to have the process thing worked out. "Extreme" and all the other crap I've had to tolerate is useless overhead written up by a bunch of career ass-coverers.
- williamdyer, on 10/12/2007, -1/+1The only process that really matters is the hiring process.
Good people will naturally find reasonable ways to organize projects. One sociopath can ***** it up for 50 good people. If you can't keep the sociopaths out, you are ***** no matter what process you use. - jarielbs, on 10/12/2007, -0/+1Process can detract from the real goal of getting a product out. The best process I have seen is to ensure that the end product is of high quality and can be manufactured repeatedly at a low cost.
The biggest mistake people make in process creation is putting in too many micro-checks and not letting people just do the work. There should be hard macro-gates (like code complete, design done, schematic complete) and those should be well defined, with clear deliverables that everyone agrees to.
Digg is coming to a city (and computer) near you! Check out all the details on our 
© Digg Inc. 2008 — Content posted by Digg users is