Original English: Why Software Development Methodologies Suck
Source of translation: Why does software development methodology make you feel bad?
There are always many dogmatic rhetoric around software development practices and methodology. Can the phase-gate approach effectively manage the risks of the software development process, or is it just a fancy gimmick in risk management? Can TDD really produce high-quality software? Is pair programming an effective alternative to code review or does it just increase the cost of negotiation and communication? I want to say that although there is no evidence to judge the fallacy of these arguments, there are two commonly used rules that can help us choose good practices and at the same time increase the value of the software we provide: shorten the development cycle and improve feedback efficiency.
Michael Feathers gave the following point of view:
I think that in the end, we still have to rely on the ability of the developers, this is a more important consideration, rather than which language to choose or entangled in the nuances of methodologies [1]. Frankly speaking, we are all aware of this, but we seem to be overly entangled in development capabilities as a key factor. Perhaps this is an extension of a widely accepted view in economics, but if people can be easily rotated (anyone can be up to it), then it is ideal.
The question is, how can we find developers with (appropriate) skills? The IT industry has never well defined individual productivity. From this point of view, finding developers with the right skills is a difficult problem to solve. Lines of code-still a mainstream measurement method-is stuck in the quagmire of "one line of code, one responsibility", which is not a good method. Measuring hours worked is to encourage (individual) heroic actions-experience has shown that “heroes” are usually the people who cause project delays. Relying on “heroes” is often a risky action that should not be taken at the beginning. Work causes people to become dull and leads to low-quality software. At present, there is no universally accepted series of standards and employment paradigms for IT professionals. Recruiting good talents is an art of (recruitment), not a project of (recruitment).
Psychologists have at least studied this question: Why are IT skills difficult to master and measure? Daniel Kahneman said (Thinking Fast and Slow) that there are two basic conditions for mastering skills: an environment is sufficiently regular to be predictable; and there is an opportunity to learn and master these regularities through long-term practice.
However, typical software projects often have irregular and predictable environments. The only correct measure of project success is: Has the final result achieved the expected goal through implementation throughout the life cycle? It is difficult to know what key activities led to the success and failure of the project, and few people can get the answer through old or existing projects. It is almost impossible to determine which decisions led to success or failure (in the field of artificial intelligence, this is called the trust distribution problem).
These factors make it difficult for IT professionals to master the capabilities needed to guide products and services to success. However, the skills that developers have to help them reach their goals more efficiently will make them more motivated-usually referred to as "development completion", as quickly as possible, regardless of whether the functions are integrated and production-ready. Similar scenarios often appear in other functional implementation areas.
The actual software project is complex and there are no rules to follow, which will lead to another problem-it is extremely difficult to collect relevant data in order to prove that a certain technology, practice and methodology is actually effective, and it is almost impossible to get out of the collection environment Summarize these data below.
In Laurent Bossavit's good book The Leprechauns of Software Engineering, he attacked some of the habits of software development, such as "cost change" (or "defect cost") and "curve", which are many other software development methodological knowledge Basically, the change in developer productivity is an order of magnitude (refer to the principle of certainty pyramid). Laurent Bossavit explained the basis-many people rely on informal experiments conducted by computer science students or collect small amounts of data from projects that cannot be effectively controlled. The basis of the arguments given by these research organizations is often not sound, the data lacks analysis, and the most excessive is that the survey results are generally far beyond their applicable fields.
Therefore, it is not possible to easily conclude that agile development practices are more appropriate than waterfall models and vice versa. The insights of "method masters" are actually not very instructive. Just like Kahneman said, "People’s confidence in ideas is not a factor that can be relied on for effective actions... When evaluating the ideas of experts, even when there is a rule to follow. Under the circumstances, you must also think about the possibility of introducing their ideas at the right time." As Ben Butler-Cole pointed out (why software development methodologies rock), introducing a new method often has some impact.
You might think that when we decide how to operate a team, we fall into passivity. But think about why software development has no rules to follow? Why is it difficult to conduct some experiments and acquire skills in this environment? What practices and decisions will lead to success or failure? The root cause is that the environment is irregular, and the feedback process between making changes and understanding the results of the changes is too long. The term "change" here refers to changes in requirements, method changes, development practices, business plan changes, code or configuration changes in a broad sense.
There are still some ways to help shorten the cycle, such as when we apply lean software development ideas-a very important method. Shortening the development cycle is very important in large-scale product development: In Bret Victor’s wonderful video Inventing on Principle, it is mentioned, “So many innovations are discovered, as long as you truly understand what you are doing, you can discover anything. ".
But it’s like this for me: it’s almost impossible for us to practice continuous improvement, learn how to make teams or individuals better, and master the skills needed to successfully create large-scale products and services. Unless we focus on shortening the feedback interval as much as possible, in order to actually gain insight into the relationship and identify the cause and impact.
In fact, the advantage of the shortest possible cycle from idea to feedback is so obvious and important that it should be regarded as an important principle to be followed in the business model. If you are entangled in whether you want to create your product as a user-installed software or the SaaS model (software-as-a-service, software operation service model, software as a service), then the idea will naturally push you to strongly consider SaaS model (sent after feelings). If you want to rebuild your system (including hardware), you should consider how you can get prototypes out as quickly as possible, as well as modular hardware and software so that you can integrate quickly and independently. 3D printing (three-dimensional printing technology) technology seems to have a huge use in this regard, because it can meet the evolution of software development and application practices to hardware systems (prototype presentation). If you want to shorten the cycle as you wish, it is necessary to operate more or less as cross-functional teams.
Software methodology, even hiring a group of great people and letting them organize themselves is bad, because they often get "cargo-cult" (cargo worship, well-known short stories in agile development, metaphysical): we are doing stand-ups (every Daily stand-up meetings), we have a priority backlog (priority to-do business), and we even practice continuous integration for the sake of God. Why is our final result so bad? Because you forgot the most important thing: to build an organization with good learning ability and adaptability.