It's NOT the code NOR the process, stupid!
It looks like some people think that focusing on a process and having a high level view will yield more successful projects.I have to disagree with this statement. While a process may be a good thing, in most cases the process is the cause of failure. The reason is simple, processes are often put in place for one reason. To reduce the per resource cost. It seems that executive believes that having a process will allow them to hire less skilled individuals (this really mean cheaper) and to still be able to deliver a project on time and on budget. Since the birth of software development, we have people who champion processes to executives to reduce their costs and increase the rate of success. They will often use the quality argument to support their point of view. However, even if more people use processes, the rate of successful software projects has not increased throwout the years nor the cost has decreased.
I have yet to see a project that is so trivial that it will succeed with unskilled people using a well defined process. Choosing the appropriate technology, creating an appropriate architecture and design are no trivial tasks. No process will ever make these task easier to do or more predictive. Only having the right people for the task will increase the chance of success. A process can help them, but never will replace them.
Focusing on code or focusing on processes are both wrong. Get good people on your team and focus on what really matter... What needs to be delivered! Focus on what is going to add value for the client/user. A working application will give more value than a well defined process. A process can help in achieving this as long as it's a mean but not an end.
It's NOT the code NOR the process, stupid! It's the right people focusing on the appropriate objectives!
4 comments:
Hi Emmanuel.
"Get good people on your team and focus on what really matter... It's the right people focusing on the appropriate objectives!"
How do you manage in getting good people? How do you decide if a person is good or bad? How do you decide what really matters? How you choose appropriate objectives? :-)
Hi Fabrizio,
I don't think there is an easy answer to that question. From my experience, choosing good people has been more a question of feeling. The common thread among good people is that they have a great ability at resolving problems. But this is not necessarily something that is easy to perceive in an interview. Note that resolving problem is not tied to specific knowledge. It's a general ability.
As for deciding what really matter, it is something the client/user should be able to do. He's the one who has to make decision about what is going to give him value. In most case it should have nothing to do about technology or architecture. It's a business decision that has to do about business objectives. We can give them advice to the better of our knowledge, but it is up to them to make the final choices.
If your client/user seams to focus on technology issue, then you need to redirect him to his business objectives.
When you focus on things that give business value to the client/user, then you cannot be offtrack. When you or your client loose focus on the business, then you are offtrack.
This may not directly answer your questions, but unfortunately, if there were easy answers, then most projects would be successful.
Thank for your response. I absolutely agree that there's no magic bullet for answering these. Nevertheless my point is that i call "process" the knowledge base and the decisional sequence that, good or bad, bring you to an answer. I see that, instead, for many people "process" means mostly a heavy, bureaucratic burden imposed by managers. Of course there are, unfortunately, I just call them "bad" processes.
In any case I there were a lot of interesting replies to my post, including yours. Maybe I'll go on with the discussion in a new post in the next days.
Great read thankkyou
Post a Comment