There are several approaches regarding the software development process as product delivering techniques. Well known ones are ISO and CMMI standards. Both of them defines a rigorous process model to enhance the product development through well defined processes and normative that are relating “how do you must work”, but it forgets that you are working with people and not machines. Rigorous processes can be applied to machines, not people. You need something more dynamic to really solve problems. I have worked on several companies where those standards were applied twice. On early stages using CMM and now CMMI. I was not happy with them.
tl;dr
No matter the process, without motivation and the right methodology, you will fall in mistakes.
about the process
At one side, there were rigorous process and several structured documents to fill on each process that was build as key step on the development process. Some people working on those companies can be labelled a NNPP, or bad programmers. But not by a lack of knowledge, instead of that there was a lack of motivation, which is more dangerous than lack of knowledge. That was leading some developers to commit programming mistakes, and then leading others developers to fall in monkey patching, delivering those well structured documents with non-technical descriptions about what they were doing, but a product quality that can be delivered by programmers that do not have more than two years of experience.
Many of those de-motivated programmers were expecting to be ascended to project managers or analysts, and similar roles, and they really were not wanting to program. So they were not enhancing their programming techniques, were not interested on enhancing their programming skills, and most delivered products were delivered late and with poor quality. Many times skilled programmers were assigned to do the required monkey patching to deliver the required products on their milestones, but the products were not really deliverable. I know that there still are a lot of bugs to fix. No matter how well defined, how good and how precise is your development process if you do have motivated programmers that really like to program.
Most successful companies have motivated programmers, people that really likes to learn and enhance their skill on this area. That segment is very small, so you must take care of your skilled programmers or they will leave you, searching for a company that really appreciate their skills. Those managers that have in mind only the process and have forgotten that they are working with humans, usually are derogatory with their developers. They have more faith in their process model rather than their programmers. They really forgot that the know-how is not held by the process, and cannot be hold there. No matter if you have a wide library filled with well documented how-to, the problems appear once you reach new problems to solve, and there is no documentation to supply solutions. Then you need people that can think and have enough knowledge to solve the problem.
You do not need to send your programmers to motivational talks or similar stuff. If you want to keep them in your company, you just need to be conscious about their motivation. Usually they like challenges, but not those where you pressure them to get things done where other programmers were not able to complete certain tasks. Nobody likes the monkey patching, so the best effort must be done early, not lately. You must put enough leadership in your development process to make all your programmers conscious about that. I am efficient in my programming tasks, but it is because I do my best effort early. My customers are happy with it. Obviously if you make huge changes in your project, like changing the database model and you want those changes for free, I will leave your project. I will not work for free, and I dislike those people that are doing that.
about the methodology
Currently I am using Scrum to handle the requirements through the backlog. Mainly because many of my customers are changing their requirements dynamically. On strict projects, where I must design algorithms or do some algorithm research — for example I have received a proposal for an algorithm design where apparently I must apply dynamic programming and some ranking techniques — usually the requirements are well defined from the start. But there is no human interaction on that algorithm design and the daemon that is supposed to build the rank and the index — probably I will use something similar to PageRank and MapReduce, mixed with some Levenshtein distance, Bayesian classifiers, linear classifiers, and related stuff. At the other side, where is required human interaction, probably there is a lot of input parameters that are changing in the forms that can fill the user, changing also the complete behaviour of the system, there is required a dynamic requirement management that can offer Scrum. With those changes also is required a re-estimation of milestones and project cost recalculation, or you will be working for free. So, it really depends on the product. If your customer is constantly changing requirements and you are using something rigorous like CMMI, you will fall in project loss, since you will spend more time filling documents and adjusting requirements, delivering specifications too late for your developers, mostly if you do not change your milestones.
So, your development process should be dynamically handled and use the right methodology with the right project and the right customer. You can be building a software specification for three months, but if you customer changes its own processes on those three months, that specification, the document that was written and the time spent on that, will be lost.
Entries 