Why don’t software development methodologies work? (2014)

For me, the real issue is ownership. I come from a finance background and have seen "business people" often run technology into the ground because they simply can't let go of ownership or control. They want to define too much and leave little in the hands of the developer. Development managers can be just as bad with their overarching methodologies. Really bad ones can stifle the creativity of their developers by micromanaging and just end up making people miserable. I personally don't follow any particular methodology, but instead, I agree with each team member a well defined deliverable and deadline, and just let them get on with it (with whichever methodology they prefer). The only thing we stipulate as a firm is the version control system and test procedures. The whole team has an informal chat once a week or so to make sure things fit together properly - no daily stand up rubbish. It's not complicated or even that structured, but it works and my colleagues seem happy. Basically our philosophy is, hire good people, make them responsible for something, and let them find the best way to deliver. And definitely don't tie them up in stupid admin tasks as stipulated by the latest fad.

&gt; I think programmers should pay much more attention to listening to and working with their peers than to rituals and tools, and that we should be skeptical of too much process or methodologies that promise to magically make everyone more productive.<p>Sounds pretty much like:<p>&gt; Individuals and interactions over processes and tools [1]<p>I don&#x27;t know why, but somehow people don&#x27;t get it that agile is not a methodology but a spirit.<p>[1] <a href="http:&#x2F;&#x2F;agilemanifesto.org" rel="nofollow">http:&#x2F;&#x2F;agilemanifesto.org</a>

There is such a things as physics in software: between time, scope and people, one of them almost always has to give. Exceptions I&#x27;ve seen are with mature and well-bonded teams working on familiar scope they understand clearly, with a timeline they themselves defined.<p>I&#x27;ve found the best &quot;methodology&quot; to deliver decent results are sticking with short iterations. Software is often about doing something we&#x27;ve either not done before, in a way we&#x27;ve not done it before, with people we&#x27;ve not done it with before. So we will have surprises (aka delays) on the way. The more frequent we check just what these delays are, the more realistic we can be about whether we can make it on time, or if we need to cut scope or pull in more help to make it on time.

This sits uneasily with me. I cannot remember any time when a Methodology was followed in practice. Just my bad luck?<p>The relogious people (mentioned in the article) harmed by false adherence. They adhered to the headlines and warped the substance of what the Methodology said. I remember (with pain) a place that wouldn&#x27;t develop development scaffolding. They had rules for software development, good ones, motivated by achieving near-perfect uptime for customer-facing services. Implementing a scaffolding service or crontab to that standard was a lot of work.<p>Then there&#x27;s the non-adherents who eroded the Methodology. Like the scrum shops that eroded scrum by deemphasising the product owner and stories until the result looked more like a waterfall.<p>The Methodologies may be broken as a whole but the practice I&#x27;ve seen was generally so distorting that I feel it&#x27;s unfair to blame the Methodologies.

I think methodologies could benefit by being treated like software, since that&#x27;s effectively what they are - &#x27;human&#x27; software to manage teams. That means:<p>* Frequent releases (i.e. do iterations or &#x27;sprints&#x27; or whatever).<p>* Accept that your methodology has bugs and &#x27;fix&#x27; those bugs between releases. Most software is horrible and buggy. Don&#x27;t trust the &quot;methodology gods&quot; that they wrote a perfect piece of working software. It&#x27;s probably half assed and worked semi-well for their specific use case so they &#x27;released&#x27; it along with a reality distortion field.<p>* Accept that different use cases require different methodologies. Writing space shuttle code? You need vastly different team dynamics to a group of 10 people at a marketing agency running short lived campaigns.<p>* Follow the UNIX philosophy: don&#x27;t have ONE methodology that you follow to a T - string together a bunch of small, self-contained rules and team processes that serve your purposes and iterate upon them.<p>tl;dr fuck scrum. it&#x27;s the internet explorer of methodologies.

My own view is that something analogous to Conway&#x27;s Law is at work: software design reflects the constraints inherent in the software methodology used.<p>The problem is not software methodologies per se, it is trying to apply a software methodology to software development where the priorities of the methodology are fundamentally at odds with the requirements and goals of the software being built. The root of the problem is the notion that there is one software methodology that is efficient and productive for all possible types of software development. I would argue that there is an optimal methodology for most software but it is a different methodology for different types of software.<p>If we discard the oft-argued proposition that a PHP website, an embedded system, and a high-performance database kernel can -- and should -- all be developed with the same software methodology then this entire discussion goes away. A software methodology is a tool; they work best when you select the best one for the job.

I think this is why DevOps is becoming so popular. It&#x27;s less about methodology.<p>There&#x27;s no certificate, role, set of tools or prescriptive process. There&#x27;s no specification, it&#x27;s not a product, or job title. There&#x27;s no one true voice on what DevOps is or isn&#x27;t. It&#x27;s about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It&#x27;s a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It&#x27;s a conversation. It&#x27;s about taking the best experiences and sharing those with others.

I find the problem with development &quot;methodologies&quot; are the people implementing them. Frequently the Agile Master or someone who has read the book and granted a certification but doesn&#x27;t understand the subtleties of company culture, team capabilities or project etc. They just want the &quot;process&quot; to be followed.

Seems to me yet another confirmation of the first rule of the Agile Manifesto: &quot;Individuals and interactions over processes and tools.&quot;<p>The methodology cannot be effective without creating the right personal dynamics.

There’s a difference between methods that are shown with evidence to help developers and methods that are merely marketed as such. The writeups on methodologies should distinguish between these. It’s also possible these people have thought about methodologies a long time without ever discovering the ones that work. Fagan Software Inspections, Mills’ Cleanroom Software Engineering, Meyer’s Eiffel Method, and Praxis’ Correct by Construction all worked if we’re talking about developers delivering products in acceptable timescale with low defects. They all let developers do their job in an iterative way providing extra tools or restrictions that help ensure quality and&#x2F;or maintainability.<p><a href="http:&#x2F;&#x2F;www.mfagan.com&#x2F;pdfs&#x2F;software_pioneers.pdf" rel="nofollow">http:&#x2F;&#x2F;www.mfagan.com&#x2F;pdfs&#x2F;software_pioneers.pdf</a><p><a href="http:&#x2F;&#x2F;infohost.nmt.edu&#x2F;~al&#x2F;cseet-paper.html" rel="nofollow">http:&#x2F;&#x2F;infohost.nmt.edu&#x2F;~al&#x2F;cseet-paper.html</a><p><a href="http:&#x2F;&#x2F;se.ethz.ch&#x2F;~meyer&#x2F;publications&#x2F;acm&#x2F;eiffel_sigplan.pdf" rel="nofollow">http:&#x2F;&#x2F;se.ethz.ch&#x2F;~meyer&#x2F;publications&#x2F;acm&#x2F;eiffel_sigplan.pdf</a><p><a href="http:&#x2F;&#x2F;www.anthonyhall.org&#x2F;c_by_c_secure_system.pdf" rel="nofollow">http:&#x2F;&#x2F;www.anthonyhall.org&#x2F;c_by_c_secure_system.pdf</a><p>On concurrency side, there were also SCOOP for Eiffel and Ravenscar for Ada which eliminated race conditions by design. Some methodologies in high-assurance sector were using tools like SPIN model checker for it. People spent a <i>long</i> time talking about those bugs while some design methods just removed them entirely. A lot less debugging and damage might have happened in industry with the aforementioned methods getting way better with industry investment.<p><a href="https:&#x2F;&#x2F;www.eiffel.org&#x2F;doc&#x2F;solutions&#x2F;Concurrent%20programming%20with%20SCOOP" rel="nofollow">https:&#x2F;&#x2F;www.eiffel.org&#x2F;doc&#x2F;solutions&#x2F;Concurrent%20programmin...</a>

In the age of Internet, I believe there is a way to conduct experiments that would yield an answer based on data. Spitballing here, but how about a kind of contest for &#x27;points&#x27; where a statistically significant number of devs volunteer to participate. They each provide a &#x27;resume&#x27; (GitHub, LinkedIn, CV,...) into the system. The programming task is presented and the devs self assemble into teams, and endeavor to complete the task.<p>As an example, let&#x27;s say 100 devs jump in. The task is to create a simple Android app, with a requirements statement provided, with server back end, launch it into the app store, support it for some period with bug fixes and improvements, and then declare it &#x27;1.0 released&#x27; to wrap up the experiment.<p>What you&#x27;d wind up with is a variety of team sizes, a variety of team experience, a variety of development systems used, a variety of outcomes. But all building the same software.<p>The key would be that as many attributes of each team&#x27;s efforts as possible would need to be recorded and entered as data to be studied in search of patterns.<p>Repeat this <i>n</i> times and I believe valuable insights could be gained.<p>Rather than trying to control for all the variables of team size, experience, method, you control for the end product being targeted and then look for insights into the variety of approaches that teams took.

Agile always seemed like a cargo cult.<p>When you don&#x27;t understand how or why something works, this is how you go about it. Let&#x27;s make airplane-shaped things out of coconuts.

I have a question: can someone describe something akin to what we call “methodology” in a completely different field?<p>Does “scrum for surgery” exist? What is an equivalent of “waterfall” in warfare?<p>Does something like this exist at all?

&gt; But in terms of the only measurement that really matters—satisfying requirements on time and within budget—I haven’t seen any methodology deliver consistent results.<p>Good, Fast, Cheap. Pick two.<p>That&#x27;s what you are doing when you are pitting requirements, a time frame, and a budget against each other.<p>The first problem is this is a company wide process, not just software development. The only thing development tells you is how long it will take given the budget. Development doesn&#x27;t define the requirements or the budget.<p>The third statement in the Agile Manifesto, which tends to get overlooked:<p>&quot;Customer collaboration over contract negotiation&quot;<p>That is entirely a business process and ultimately determines both the requirements and the budget. It is something that is sorely lacking at most companies, regardless of how hard their engineering department tries to follow agile. It doesn&#x27;t work without the full company buy-in.

&gt; Try this thought experiment: Imagine two teams of programmers, working with identical requirements, schedules, and budgets, in the same environment, with the same language and development tools. One team uses waterfall&#x2F;BDUF, the other uses agile techniques. It’s obvious this isn’t a good experiment: The individual skills and personalities of the team members, and how they communicate with each other, will have a much bigger effect than the methodology.<p>Another thought experiment: imagine getting two teams of programmers using the same methodologies and everything else and expecting the results to be the same. It&#x27;s just not practical to perform studies like this because there are too many variables.

Software methodologies don&#x27;t work because we&#x27;re not getting the fundamentals of software development right. Reorganizing your kitchen layout won&#x27;t help your restaurants if your chefs are still struggling to make scrambled eggs.<p>The most important thing any software team needs is proper logging, monitoring and metrics. No matter how great your process and engineering culture, you&#x27;ll need logging, monitoring and metrics; things will happen. The worst part is that this is relatively cheap and simple to do (at the scale that most of us operate on), with huge rewards, and most teams still do it wrong. Whether they&#x27;re logging too much noise, or collecting metrics that show what&#x27;s right vs what&#x27;s wrong, or swallowing exceptions, etc. This is the litmus test.<p>Next are automated tests. Unit tests, integration tests and fuzz testing. The downside with this is that it takes a long time to master. Yes, it costs time at first, but that&#x27;s why you have senior developers who should be able to use tests to save time and teach others from their mistakes (like too much mocking).<p>Finally, code reviews and pair programming. Almost every line of code is an opportunity to teach and to learn. No methodology or tool can help if you hire junior programmers and don&#x27;t do pair programming (or some other really involved mentoring, but I don&#x27;t know of any).<p>Technical debt is real. Most of the time people don&#x27;t have time to do things right is because they didn&#x27;t take the time (or didn&#x27;t know how) to do things right in the first place.

I don&#x27;t particularly think the methodology merchants are in the business of improving software development. Their bottom line is affected by selling trainings, consultancy and certificates, thus the single metric of a methodology working is whether and how fast it can grow its user base, keep them happy and coming back for more. It might loosely correlate with improving software quality, but that is entirely secondary.

They don&#x27;t work because it seems most places treat software development as a function separate from whatever the company does (with the exception of software companies which rarely follow one &quot;methodology&quot; but just do what works for them). Software is a way to tell a computer how to produce an outcome. The more important thing is how that outcome fits into the business, not the method of reaching it.

I like the article, and agree mostly. Though I&#x27;ve come to look at it a little different.<p>Agile&#x2F;waterfall&#x2F;etc are PM methodologies used to manage software devt projects. Especially Agile has limited use beyond software devt.<p>Methods of deving software are things like: domain driven, data models first, TDD, etc.<p>Then there are programming paradigms: OOP, FP, Actor based, etc.<p>So the set of &quot;techniques&quot; the article lists in one list are of different types. All of these have to be evaluated against the people that have to use them (don&#x27;t for OOP on an FP team, or vise versa) and the type of problem to be solved (TDD is less usefull for a simple UI project, than for a complex algorithm involving time and lots of corner cases).

&quot;Whether a methodology works or not depends on the criteria: team productivity, happiness, retention, conformity, predictability, accountability, communication, lines per day, man-months, code quality, artifacts produced, etc. Every methodology works if you measure the right thing. But in terms of the only measurement that really matters—satisfying requirements on time and within budget—I haven’t seen any methodology deliver consistent results.&quot;<p>You star with a premise that requirements, time constraint and budget are all set magically right before the project began.

I find if you have excellent programmers who enjoy the problem they are working on and are put under the right amount of pressure you get great software no matter what process is followed.

The thing that I feel these methodologies solve is reminding developers of the users.<p>Ultimately a lot of people tend to lose track of higher level objectives when working on the (admittedly complex at times) implementation details. This is probably the biggest productivity killer in the business<p>How many of us have had that first demo with some people external to the dev team and for all the feedback to be super obvious things that could have been caught before a single line of code was written?

Because software has uncertainty (about requirements, environment, tolerances, complexity) and creative elements thrown in.<p>It&#x27;s not a regular pipeline kind of workflow, like some Taylor-inspired assembly line, or regular old civic engineering.<p>Besides all those methodologies are unscientific BS invented by consultants, not something derived from actual studies (even when there are some comparative studies involved they are laughable in scope by scientific standards).

The author misunderstands what methodology is. TDD is a single practice, not a methodology. OOP is a way of structuring code, not a methodology.<p>What I have seen work is methodologies adopted to get the benefits of what the methodology actually delivers. Not a checkbox so say &quot;we are X&quot;.

Software is no different than any other engineering discipline. We absolutely do have software development methodologies that work, we have decided to exchange speed for quality.<p>Better, faster, cheaper, you get to choose 2 and only 2, we&#x27;ve selected faster and cheaper.

This article is unreadable on my phone. All I see is the immovable side-bar filling 80% of the screen with &quot;hire me&quot; in the middle. Ah, no thanks!

<a href="http:&#x2F;&#x2F;programming-motherfucker.com" rel="nofollow">http:&#x2F;&#x2F;programming-motherfucker.com</a><p>The one true methodology. Preach!

I spend more time now on asinine meetings than writing code. Must be some kind of ironic hell. Needless to say, I agree.

Some great comments here. Does anyone mind if I link to this thread from the original article?

It sounds like author is not too fond of code reviews, test approaches, and linting rules. These things are based on personal preference and semi-religious beliefs often leading to conflicts, even on two person team.

No silver bullet

&gt; satisfying requirements on time and within budget—I haven’t seen any methodology deliver consistent results<p>There seems to be a false premise. Methodologies don&#x27;t deliver consistent results on time and within budget because they attempt to help to figure out those software requirements, so that an actual problem can be solved, not useless requirements satisfied.

&gt; Maybe social skills come harder to programmers than to other people (I’m not convinced that’s true)<p>This is, in fact, the answer.<p>You haven&#x27;t truly SEEN office politics until you&#x27;ve worked on a team of developers. I&#x27;m shocked a reality show hasn&#x27;t come out yet about software development. It would make Survivor look like Family Matters.