After reading many of the development process-related pages on this wiki, and comparing with my own observations and what others are saying, I've come to a few conclusions about software development processes.

	* People like to talk about processes, and find new ways to get a process that addresses all of the shortcomings of prior processes, and seeks to achieve a higher level of quality from a given pool of programmers.
	* Processes tend to aim for the middle of the curve, so that 80% of the software projects can be easily represented in terms of the project rules and steps. The other 20% must somehow be coerced into the domain of the development process.
	* Processes, in and of themselves, add no value to a software development team. It is near impossible to come up with a perfect process that will allow an army of variously skilled programmers come up with good product every time.

I believe the trick lies in having good developers who understand how to write good software, and use a process as a means of ensuring consistency between them and between subsequent projects, rather than trying to coerce good code out of a less-than-ideal development team.

Along these lines, it must be noted that not every process will work for every team. Obviously you cannot expect to do pair programming when you are the sole developer of a product.

--JacobCohen

----

''Processes, in and of themselves, add no value to a software development team.''

I'm fairly sure that isn't quite right. My take on this is that the absence of process - or, if you will, of a reasoned discipline - detracts from the value of the team, for any team, at any time. One of the least mismanaged projects I ever had the pleasure to work on was a geographically distributed effort split among two teams of three people each some hundreds of miles apart, without benefit of testing and without pairs. We did have strong autonomy as to scope, adequate talent, nearly continuous integration, and absolutely no outside distractions. We shipped late and buggy, but neither ''too'' late nor ''too'' buggy.

''I still believe that putting a process in place does not of itself increase the productivity of the team. A carefully designed and tailored process may help ensure consistency and smoothness in a good team, but a process can do as much harm as good, especially if the process is enacted to try to move past the "hero model" of programming without addressing the problems underlying the situation: you have a lot of developers and only a few of them get actual work done. In these cases, a process isn't going to cure anything and might encumber the people who actually get work done.''

Do you find processes slow you down? If so, are you sure you are using the right process for what you are doing? I have found that processes address not the shortcomings of other processes but the shortcomings of the team. If my team consistently needs documentation (or whatever) it doesn't have, the process should specify a higher level of documentation. But if an element slows me down, why not stop doing it? In the end, I am left with the bare essentials. These essentials allow me to deliver my product on time and bug-free. Nothing more.

''Exactly. That was part of my point, but from your response I gather that you are in a situation where you dictate the process. Many organizations have such a structure where the employees must follow a process that they have no part in designing, especially larger firms that are striving for a higher CMM rating. I have seen cases where people higher up in the company believe that they can achieve more productivity and better code if they begin defining how the programmers should code, and even what the code should look like (coding standards, management often seems to think that hungarian notation is the best idea since sliced bread). Not that coding standards are all bad. I believe that you can and should define a standard of some common conventions to follow so that you can work on separate pieces of a project and have a reasonable idea of what the other parts are doing, but this is more a side-effect of a good project design, rather than something in place to create better designs. For example, always naming the method that returns a hash code for an object "hashCode" (as Java does), versus always prefixing a member variable with m_. Another example, always overriding hashCode() when you override equals() and vice versa (another Java example) versus explicitly having a get and set method for every private member variable of a class. You don't need a get/set method for the socket file descriptor within a socket class if the class is designed to hide the socket library interactions from the user.''