Why don’t software development methodologies work?

This article got some great commments. Scroll down to read those.

I’ve worked on big projects, small projects, in huge teams and by myself, in fossilized federal agencies and cool Silicon Valley companies. I have learned and used at least twenty programming languages. I’ve lived through waterfall/BDUF (big design up front), structured programming, top-down, bottom-up, modular design, components, agile, Scrum, extreme, TDD, OOP, rapid prototyping, RAD, and probably others I’ve forgotten about. I’m not convinced any of these things work.

[Edit: Let me explain what I mean by writing methodologies “don’t work.” I mean they don’t deliver a predictable or repeatable software development process in and of themselves. I don’t mean that using a methodology dooms the project. Most software development methodologies try to make programming a more engineering-like process, and in that regard they fall short.]

How can you tell if a methodology works?

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.

My own experiences are anecdotal, but they are shared by almost every programmer I know. It turns out that anecdotes are all that anyone has: rigorous studies of software development methodologies haven’t been done because it’s impossible to control for all of the variables.

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/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.

In his 2003 thesis People and methodologies in software development Alistair Cockburn concludes “People’s characteristics, which vary from person to person and even from moment to moment, form a first-order driver of the team’s behavior and results. Such issues as how well they get along with each other and the fit (or misfit) of their personal characteristics with their job roles create significant, project-specific constraints on the methodology. This result indicates that people’s personal characteristics place a limit on the effect of methodologies in general.”

Our own worst enemy

When I started programming in the 1970s software development was tightly controlled by management through a hierarchy of project managers, business analysts, and senior programmers. We did not get to pick the language or tools. I worked on some big, complex projects in companies that worked this way. Some succeeded, some didn’t. Now it’s common for the programmers to choose the methodology and style of working, along with their languages and tools. Analysts are not part of most programmer’s experience anymore, and project managers have been reduced to “team leads” and “Scrum masters,” neutered of any managerial authority and not really in control of anything other than rituals dictated by team consensus.

Strict management, in love with Gantt charts and schedules and documentation, was reduced to “stakeholders” and “users,” and then abstracted away into “user stories.” It’s common now for me to get involved in a project that seems to have no adult supervision. Surprisingly, left to themselves programmers don’t revert to cowboy coding—they adopt or create methodologies stricter and more filled with ritual than anything I experienced in 1980. In fact programmers today can be much more rigid and religious about their methodologies than they imagine a 1970s-era COBOL shop was. I now routinely get involved with projects developed by one or two people burdened with so much process and “best practices” that almost nothing of real value is produced.

Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision.

Does anything work?

My own experience, validated by Cockburn’s thesis and Frederick Brooks in No Silver Bullet, is that software development projects succeed when the key people on the team share a common vision, what Brooks calls “conceptual integrity.” This doesn’t arise from any particular methodology, and can happen in the absence of anything resembling a process. I know the feeling working on a team where everyone clicks and things just get done. What I don’t understand is why I had that feeling a lot more in the bad old days of BDUF and business analysts than I do now.

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. Maybe social skills come harder to programmers than to other people (I’m not convinced that’s true), but developing those skills will certainly pay off a lot more than trying yet another development methodology.

[Giles Bowkett published an excellent take-down of Scrum that ties in with this article. He covers the shortcomings of Scrum and how “agile” is practiced in real life in more (and funnier) detail than I got into here: Why Scrum Should Basically Just Die In A Fire

Comments

Keith on 10 February 2014 at 7:45 am

Amen Brother.

Gordon Morehouse on 10 February 2014 at 7:49 am

Heck, I’m green enough that I went straight from cowboy coding to something resembling Agile and then achieved my ‘grizzled veteran’ stage of programmer incompetence (search that, it’s funny) with Agile. The only time I’ve seen it “work” in any real sense is on projects undertaken with programmers who are also my friends. Otherwise – at best – it can wring a little more customer-focused work out of a dysfunctional team. I don’t know if this was true in BDUF days, but it’s my sense that in Agile, team dysfunction is usually lack of a product manager and/or terrible executive management before personal conflicts get a nod.

Paul W Homer on 10 February 2014 at 8:03 am

My experience is similar, what is often behind a high-functioning team is talented people who communicate well about a shared vision. The methodology helps, but if the other characteristics are missing than things won’t function. I have found that an overall culture of engineering at the organizational level is necessary for the initial creation of teams. The same group of developers working in a bad environment just won’t gel.

I do worry that the overall gamification of software development has shifted the focus away from producing quality results and onto less critical goals. What counts in the end is the quality of the system and whether or not it actually makes the user’s lives easier or better. Everything else is secondary.

Fred Zisk on 10 February 2014 at 8:24 am

The only method that seems to work is Waterfall. You have to know what you need to produce, design it thoroughly, and know the technology and solutions you are presenting. If there are any ‘unknowns’ things go awry. Only very experienced devs (10+ years) can spot hidden unknowns that deep six a lot of projects.

Bjorn Louser on 10 February 2014 at 8:36 am

“Surprisingly, left to themselves programmers don’t revert to cowboy coding—they adopt or create methodologies stricter and more filled with ritual than anything I experienced in 1980.”

Programmers today artificially inflate the complexity of their work under the guise of ‘best practices’ in the hope that it will create job security and lead others to perceive them as experts in the field.

It’s just the delusional thinking of generalists whose contributions to the product are as well regarded within the company as the efforts of the office custodial staff.

The lack of fear for the evil that lurks beneath the fingers of a subpar programmer leaves this neutered ‘profession’ with no recourse but to build monuments to itself through a religion of methodology.

Daniel Meyer on 6 September 2015 at 11:37 am

Your statement was so accurate I had to send you this response. I have been programming and in development for 35 years. From COBOL to .NET. I have worked for major technology corporations. Our current batch of programmers are “pretenders”, that do not respect or care about development, they are more concerned with CTOA’s so they can make money. It got so bad that I went independent, and I am now working on my own. I absolutely love the freedom of being able to create my own programs faster and more efficiently than any of the past development teams I have been on in the past five years. So to all the “pretenders” out there. Thank you 🙂

Chuck Norris on 10 February 2014 at 9:40 am

I agree that a common vision is needed. It’s also interesting that MVVG (mission, vision, values, and goals) are some of the first things that B-schools teach.

Jon on 10 February 2014 at 9:44 am

I like your article, and I get it. In my personal experiences, I have found that scrum is successful when it is used to reinforce a single coherent vision and to build a tight integrated team.

It does not work when it’s used as a magic machine of happy fun time productivity…. Sprints and stories don’t translate into more productivity. Focus and teamwork do.

Ashish Jain on 10 February 2014 at 9:50 am

I am the one, who is big fan of agility and least fan of any methodologies. Recent pattern I have observed (and currently facing), stakeholders wants to use newer methodologies to hide basic problems with projects, like not enough competent team, not enough clear goals for quarter or year. They think, using agile practices, things will fall into place automatic. That’s what everyone says.

In end, developers are spending 50% of their time in managing tasks, not really doing it. And little time they get, they just finish it off.

Tom Moxon on 10 February 2014 at 9:52 am

Nice Article Greg, I couldn’t agree more. However, I would also add that “the Vision thing” matters the most – someone who can visualize all the pieces, protocol, cogs, and gears working together. IMHO, without that – all big projects fail…

calvin on 10 February 2014 at 9:54 am

The only “methodology” I’ve read that I have seen consistently work in action is the one described in the mythical man month. (the author used a surgical team as the model) A single technical lead with full authority to make decisions, with a next tier assistant, associated technical staff, and a non-technical support person. the achievement of the team is then determined by the leadership of the team. the size of the team and project complexity is then limited by the leader and her ability to understand the problem and assign tasks. it prevents death by committee, it creates ownership, the size of the team is optimized. methodologies go into that, but only that they serve a purpose for the team and the production.

mark andreeson, steve jobs, elon musk. are famous examples of this model. And while I don’t know if it’s in MMM, the leader should arise, and not be appointed by management. The team knows who should be leader, there should be no conflict of title and ability. nothing dooms a project quicker than a leader who cannot lead a technical team. it’s about the act of an ability to take charge vs being put in charge.

noname on 10 February 2014 at 10:09 am

collaborative work sucks, esp in a git environment

Chuck on 10 February 2014 at 10:38 am

The issue with methodologies seems to lie with the misconception that it’s a cookbook that doesn’t require any thinking, deep or otherwise. Too often I’ve heard people say “just follow the methodology and it will just work” without understanding that methodologies are just frameworks that need to be tailored to the problem at hand. If the cookbook approach worked and required no additional thinking then we wouldn’t need people to build things because it could simply be automated. Having said that, there are a large number of things that likely should be automated so that people can focus on solving problems, not inventing new boilerplate methodologies.

topher on 10 February 2014 at 11:07 am

I always think of the following quote when someone is advocating that a tool/process/methodology will solve all the problems: “Life is pain, Highness! Anyone who says differently is selling something.”

Brooks was right, there is no silver bullet.

What I’ve seen work:

1. Get the smallest number of the smartest people possible together.
2. Give them a clear goal.
3. Get out of the way.

Gates VP on 10 February 2014 at 11:10 am

The reason for all of this conflict in “what works” with Software Development Methodologies is simply that there is no one “software”. The methodology for creating the software depends necessarily on the the purpose of the software and the needs of the people using the software.

Facebook’s Zuckerberg famously touts “Move Fast and Break Things”. That’s a reasonable idea in web apps that are continuously deployed 10 times / day. It’s completely useless while building Mars lander software or the banking software that makes sure you get your paycheck. Clearly a bad idea if you’re building the next Therac machine, right?

But lots of software lives in between. Could healthcare.gov have succeeded with “Move Fast & Break Things”? Well ostensibly that’s exactly what they did and in a year or so it will probably be functional, if only by virtue of trading off massive user headaches.

And as much as some groups would like to tout things like TDD, I’ve never met a database that ships with its own mocks, meaning that systems will fail regardless of their ability to pass unit tests. That stated, some form of automated testing has proven to be an improvement in basically every environment I’ve seen it used. But it has a real cost trade-off.

At the end of the day, the tooling and methodologies you use are tightly coupled to the product you’re developing. In many cases, managers and academics are still trying to quantify the trade-offs being made.

And all of the this is regardless of the team involved. Clearly, good vision and the right caliber of team will help smooth over the methodology problems. But methodology is about enabling “everyone” to succeed, not just the all-stars.

Ayan on 10 February 2014 at 11:24 am

I’ve struggled with the idea of finding the most efficient usage of time. Even after reading the comments and this article, I’m still disheartened from looking for the “perfect model”. Maybe that’s just how other perfect things work: they don’t exist.

However, and in in the tiniest part, your point on developing social skills might be just that: the ‘perfect’ plan. Of course it’s not perfect because us, the people are not, but it’s personalized and adaptive. Listening, analyzing, and measuring how your team works best, while being knowledgeable about all these ways of working sounds like a great plan. What we need to measure, how alert we need to be to our teams, and how we can grow and learn fast, while having the experience to avoid the pitfalls, is paramount in this methodology.

Anyways, thanks for the read and for sharing your experience.

Hein B on 10 February 2014 at 12:01 pm

Biggest problem is a bunch of introverts not communicating.

Clark on 10 February 2014 at 4:12 pm

We’ve discussed this a lot lately where I work, so I have a long stream of thoughts on the issue. I can relate to poor team communication, having worked with developers who either do not communicate enough and put the team out of sync, and also those developers who turn certain practices into a religion and demand strict adherence.

I would agree that a methodology that consistently satisfies requirements on time and within budget is one that “works,” but only for projects in which requirements never change, architectural decisions never need to be revisited, and time/budget requirements are immediately obvious at the beginning of the project’s lifespan (this sort of project would be a great fit for waterfall/BDUF).

Requirements change frequently, of course. How much effort should you spend nailing down a specific, achievable deadline at a stage in the project when you know the least about what the end product will look like? Would a 4 week delay be a deal-breaker? How about 8-12 weeks? Are the customer’s margins so narrow that any development methodology failing to meet or beat a somewhat arbitrary deadline is not “working”?

Improving developers’ listening and interpersonal skills might do more for productivity and success than finding the right methodology, for many teams. This absolutely doesn’t mean finding and following a good methodology is not important.

You would also be right to say that a driver’s skill and attention to the road and other vehicles does far more to get the vehicle safely to its destination in a timely manner than his choice of which route to take, or the presence of signals and signs that require adherence to certain traffic laws. Many freeways have too much traffic. Sometimes alarming amounts of your drive time is spent waiting at traffic lights at intersections. Does this diminish the importance of building roads, placing traffic signals, and requiring every driver on the road to follow a common set of rules and procedures while driving? At most, it seems to me these inefficiencies call for a new round of evaluation and improvement, so they become things that facilitate your safe journey to a desired destination, rather than a hindrance.

I’m not forgetting the possibility that a skilled HR department can put together a dream team of developers that bring with them a depth of technical skill and near precog-level interpersonal skills, allowing effective collaboration to begin on day one of each project. They are obviously hard to find and recruit, and this requires specific language when posting job openings (”rockstar”, “10x”, “superstar”, “ninja”). Barring such a team, it’s probably safe to assume we’ll continue working on teams with developers of mixed ability and communication skills.

I believe that scrum/agile methodologies can be extremely effective when implemented in a way that makes sense for the team/company. We don’t need to be overburdened with processes and SOP’s. Ceremony for the sake of ceremony shouldn’t be an unavoidable consequence of our process, and the use of an underlying process doesn’t preclude effective communication.

Jakob Martienz on 10 February 2014 at 5:22 pm

Glad people like you are wrting about this.

So True:

“Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision.”

Ricki on 10 February 2014 at 6:31 pm

Great article! After 10+ years of coding let me share the one programming methodology that has worked somehow consistently, at least for me, my style and the skills of the help I hire. I call it “the funnel”. These are the assumptions:

1. Specs will change: guesstimate, lie about the due date and charge double.
2. Mostly we work on business-type software, process automations, so what we normally develop is a CRUD with some custom logic on update events (oversimplification, I know). Hence: deliver a prototype super fast (even with incomplete/unknown data models) and let the user “discover” the missing pieces of the specs while using the prototype.
3. Repeat cycle 1-2, funnel the client into the desired solution.
4. When analyzing the initial specs, I identify the “challenges”, the real programming, the things we cannot count on a framework/plugin to solve, the stuff we have not done before. I put someone to work on just that task and plug it into the final product when ready. Recent real example: client wants a mobile app that scans docs/reads OCR/persists on user account. Everything aside from the “read OCR” is pretty much a copy/paste client/API CRUD, we can do that in a few days. However, the challenge we work with one programmer, best ninja for the job, outsource if necessary, and when ready plug it in.

Why I think this works?

1,2 and 3 are repetitive tasks, these can be treated as engineered software development, a factory of code, measurable, predictable.

4 is creative work. The “art of programming”. It cannot be put under “project management”. If lucky it comes out in a few days, normally a few weeks or even months. Programmers are not robots (sorry managers this is true!)

Finally challenges can also be non-programming tasks: ever had to deal with 20+ rounds of UI graphic design approval? What about designing the right scalable infrastructure? Security? These challenges while not programming are nevertheless crucial for project success. They require a different methodology depending on each case.

Aahz on 10 February 2014 at 9:08 pm

I agree with you strategically but disagree tactically. That is, over-arching methodologies fail, but there are things we as a discipline have learned over the years that can be applied in almost every environment. Just a couple of examples:

• Use source control. Preferably with a culture that encourages/forces decent commit comments.
• Have some kind of automated testing — you can’t refactor easily (or sometimes at all) without it.

scaringella on 10 February 2014 at 11:17 pm

Same problems in France ….. Programmers come from the engineering/scientific field most of the time. That’s the problem.

Lonny Eachus on 10 February 2014 at 11:39 pm

In my experience, some of them (waterfall for example) don’t work simply because they’re dysfunctional as designed.

Others don’t work because very few actually do them right. For example I worked in one “Agile” shop that was great. People were good, it got the job done, and people actually did it as they were supposed to.

I worked in another shop that called itself “Agile” but in reality was anything but. They just used the informal trappings of agile as an excuse to really have a policy of “We will throw any features we want at you at any time. And, oh… no, you don’t get any time to do any of that useless refactoring stuff.” It was even worse than just regular top-down.

Guess which of those two I liked working for?

Micky Kurniawan on 10 February 2014 at 11:58 pm

Nice share 🙂

Magnus Gustin on 11 February 2014 at 1:13 am

Great post! I have a similar background and experiences. I like to compare to the world of team sports (say soccer, since I am european). An offence and defence strategy will of course help, but it all comes down to having the right players and a good coach who will stand up for the team. You want to have the right mix of people – workers who don’t ask too many questions, and the creative guys that will find the unexpected ways.

markG on 11 February 2014 at 1:21 am

I’ve worked in software development for close to 40 years now, started as a programmer, and been a CIO/Head of IT three times, including at corporates and start-ups. I’ve worked in and with some high quality engineering teams and used, introduced, varied, applied several different methodologies.

I would not say that software methodologies do not work, they can and do, what I do think is that it is simply not realistic to expect that a single method will be able to fit all known problem domains.

Software development is not an empirical science. You cannot explicitly define or quantify many of the tasks, unlike, say, a production line, or in construction where there are well proven industry formulae for certain tasks. So from the outset one must accept that no single methodology is likely to prove a panacea.

Organisations ideally should have a range of tools and methods to suit the business problems that they are likely to face, and select the most appropriate method during the preparation and evaluation phase, and the resources to be assigned to the project should have the maturity and flexibility to be adapatable. Any good developer worth their salt will choose the right tool for the job at hand. Similarly, in my view, any good delivery organisation should select the right mix of methods for the problem to be solved and the project manager and developers work to that method. In most organisations there is not likely to be significant variation in methods in any given year, but over time methods change, they have to. 20 years ago I was developing client-server applications in the oil industry, the same methods and techniques used their have morphed and changed over the years.

Having an adaptable approach is an ideal; it is very hard to make such a thing reality in the large corporates, mainly because their quality and compliance departments have choke holds on methods and processes, guarded by those whose annual bonus depends on adherence to process. Smaller companies often have the flex, but not the experience to make such an approach work. At two of the IT departments I set up, we agreed (myself, the architects and the developers) to use an appropriate mix of waterfall and agile methods, and that the project initiation process would involve resources qualified to make an appropriate assessment. Similarly at an organisation I worked at where there were 50 running projects concurrently and again we introduced a flexible approach.

As an aside, I do not think any single method can lay claim to be productive with repeatable results for all types of problem, there is no perfect approach. Consider for example football teams; they can be said to use methods, usually dictated by the experience of the manager and the quality of the resources. But there is no single demonstrably reliable method of guaranteeing success – the best teams are those that meld method and the individual talents into a cohesive group who work well together and enjoy their work. And that is probably the key, enjoyment. If you are surrounded by peers who, like you, enjoy the work, understand the methods and know the strengths and weaknesses of them, it will probably work, whether it is agile or waterfall.

Amit Gupta on 11 February 2014 at 2:17 am

Excellent article. It gives us insight how little has been done int he science of product development. I like author’s view on bringing how human factor, give more priority can change the course of entire product development. May be those methodologies were inspired by product development in other industries in the beginning. However, a bunch of people building product, require more of a better interpersonal chemistry, than the process itself. In modern days, where we see excellent products coming out of dorm-rooms and by even some amateurs, it’s the apt time to re-think the process oriented development methodologies.

KevB on 11 February 2014 at 3:03 am

Hate how the word ‘methodology’ has been highjacked to make following a ‘method’ sound more scientific.

If you are following a procedure, or talking about a defined procedure it is a METHOD.

If you are talking about the study of methods then it is ‘methodology’. Basic High School English, if you add ‘-ology’ to the end of a word you are talking about the study of.

Jacques on 11 February 2014 at 3:15 am

Your conclusion is the first point of the agile manefesto: individuals and interactions over processes and tools

Francis W. Porretto on 11 February 2014 at 3:26 am

There are any number of reasons why software methodologies — at least, those purveyed by institutions such as the Software Productivity Consortium and ISO — don’t deliver as hoped or expected, but one that must not be overlooked is that they keep changing. We’re overrun with methodologies du jour, and fads that accompany them.

We’re largely ignorant about how the programming mentality works. There’s some irony in that, programming being about the imposition of computerized order on chaotic human practices. Nevertheless, it’s so — and until we grasp the structure of that mentality (which might never happen) we’re doomed to flounder in our attempts to structure our approach to programming.

I recall, from a discussion of alternative currencies and currency management some years ago, a commentator saying that “Competition is a proper response to ignorance.” Well, the million-plus Americans working in software today are competing, in a fashion, through their individual approaches to their work. Perhaps the best thing we can do is just watch, and try to learn from those who do it better than we.

Ken McNamara on 11 February 2014 at 4:06 am

Success in any group effort is directly related to leadership.

Consider Steve Jobs – or more elementary Vince Lombardi.

Lombardi takes a failing team and in one season takes them almost to the championship.

How?

He understood football better than anyone else – and concentrated on the fundamentals.

AND he knew how to lead.

Try this book:

http://www.amazon.com/That-First-Season-Vince-Lombardi/dp/B004H8GM12/ref=sr_1_1?s=books&ie=UTF8&qid=1392120078&sr=1-1&keywords=that+first+season

Penguinman on 11 February 2014 at 4:25 am

Hi, you listed a few bad methodologies amongst the two good ones: ‘Top-down’, and ‘Agile’.

That is; people have to use them, not just say them.

something like this:

Focus on what your software needs to do, and hack it together quickly. Don’t worry about language, or get caught up on objects, patterns, or coding style. If there are any people on the team that argue about which editor is best, or serial port monitor application is best: Fire them. Also, if someone mentions SLOC counts to monitor productivity; Fire them.

If the software is new, or related to a new product, there is 50% chance it will fail no matter what.

So, fail early, get something working for the customer quickly..i.e hack it together with existing products, existing source. Give them 70% of the functionality, or even the 10% functionality that is most important.

Start getting feedback and test results from the end user early (within a week or two) Also, this can flow into progress payments.

Even If the product IS a success, it will take 50% longer than expected , change five times and be riddled with bugs. Avoid all these problems, by getting something into the customers hands early to test. So they can change their mind early and often.

Divide the project into small milestones, chunks..at the end of most is a workable release of the product. and feedback from the end user. Be it one application in one language, or a string of applications and services cobbled together performing whatever you need to perform. etc.

I hope you get the gist. I think the difference between (Top-down, Agile, product functionality focus) and (Bottom up, structured , methodology, code-factory focus) is: millions of dollars and months of work.

Forget about the last project,

Start with the new requirements, and find the best and newest tools to meet them.

(In my humble opinion)

Mike Breeden on 11 February 2014 at 4:31 am

This is a great article. I think I can add a couple useful comments. (Programmer about 20 years) I recently worked in a very progressive software development shop. I say that positively, because they were smart, dedicated people. We used Agile. They were good, so I wanted to see what Agile offered. Like the author said, it’s about how you use it. I did see one weakness. They seemed to lack any overall vision, such as you base Waterfall or BDUF on. Agile is fine, but I suggest you add that vision to it.

Another point I say is that I have often had the task of fixing Programmer Art and Programmer Junk. Not sure which is worse. It is not surprising that a highly intelligent developer creates art, but it can be a problem to avoid. We need business code or you’re gonna need someone like me.

Remember, from every strength comes weakness and from every weakness comes strength.

Sean Farrell on 11 February 2014 at 4:50 am

If you look at it methodologies are primarily about communication. The Waterfall Model tried to get everything onto paper so that it was obvious. The agile practices like stand up meetings or kan ban are about enabling communication between developers and ensuring that everybody is in the loop.

If you have a good team people will just talk to each other and any additional forced communication is perceived as a burden. On the other hand dysfunctional / semi-functional teams the methodology sort of force them to communicate, which raises the odds that the project will succeed.

I think most methodologies are mostly about average results. That means you can get bad to average developers to produce average results, but it comes at the cost that stellar developers are also slowed down to the average level.

I personally think the best thing you can do is get a small group of stellar developers, ensure that they work together and get out of their way. (Yes it sort of was said here already.)

Greg Jorgensen on 11 February 2014 at 4:53 am

@Jacques: I am a big fan of the Agile Manifesto. My experience in so-called “agile” teams is that it’s a buzzword that appeals to management and an excuse for more process.

@KevB: Thanks for schooling me on the correct usage of “methodology.” The dictionaries I consulted have mostly succumbed to the same error, but keep fighting the good fight.

Mike Valverde on 11 February 2014 at 5:07 am

“satisfying requirement on time and within budget”

I have never (in 15 years of software development) worked on a project large or small that the project due date was not already determined and promised to executive management before we even began working on the project. It seems that the due date must be the most import aspect of a project, since it is always determined before requirements, scope of work, features requests, design and implementation plans.

A Scrum Master on 11 February 2014 at 6:00 am

I feel I must defend the agile / Scrum camp here.

The blog post boils down to: Independent of the process in place, the team must function as a group. The author says that when a “few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion”, then “The resulting passive-aggression kills productivity faster than any methodology or technology decision.”

Well, that is really not much of an insight, I think that goes without saying. But how can you deduce from this that “Scrum, TDD, OOP”.. do not work? Let’s just look at Scrum here.

Almost all of the Scrum Master training, and most of the communication in e.g. Scrum alliance mailing lists, revolves around human factors like that. Technology is not an issue there, tools to a certain extend (but much more tools for maintaining your Scrum artifacts like backlog and burndown charts, not development tools). Every Scrum Master worth the job title is very well aware of group dynamics like these and will try to restrict/rechannel them.

Promoting a common vision is a major part of the job, every sprint even is supposed to have a “theme”. Many will try to make architecture a team effort, try to find an iterative approach to it etc., and avoid to have one team member dictating decisions.

I have had both successes and failures with Scrum, where the reasons for the failures could be tracked down to ignoring some important guidelines despite knowing better. Today I would say if done right, Scrum & lean development work very well.

I think the author has a) not really understood what Scrum is about (because it addresses exactly what he says needs addressing, group dynamics, common vision and such), and b) has worked with a Scrum Master that was maybe not focussed, or experienced, or trained enough. One should not condemn Scrum on those grounds.

Greg Jorgensen on 11 February 2014 at 6:19 am

@Mike I have had the same experience with schedules. That’s how business works, though. The problem isn’t usually the due date. The problem is that requirements change and expand against the due date. Programmers bear some responsibility for agreeing to one change after another and not alerting management when it’s clear the schedule is unrealistic. Management is often unwilling to listen to the warnings, and choose to throw more people at the project, which of course makes it later.

Steve Naidamast on 11 February 2014 at 6:24 am

Bravo !!!

As a senior software engineer who started in the field in 1974 I know exactly what the author of this essay is talking about. Like design-patterns, most software development methodologies are solutions looking for problems. There is only one way to design a software system or application and that is the tried and true method of the “waterfall” approach, which when taken down to its barest essential primarily demands up-front analysis and design, then coding, which is subsequently tested.

No software development technique since has been able to get away from such a basic format no matter how much you spice it up with fancy terminology or try to change the perspective on different aspects of such techniques.

If any of you follow senior software engineering analyst, Stephen McConnell, you will note that in his classic 1996 text, “Rapid Application Development”, he demonstrates 13 known software development techniques, all of which in the end implement some level of the waterfall approach.

Good software is a result of competent individual professionals working together or alone to make a quality product. Business development environments always promote “development by committee”, unless of course you are the only developer on staff. In any event, a “committee” has never designed anything of worth providing the reason for why most business software is so poor in quality. But every now and then you do get a business team that produces something of quality. Unfortunately, that experience for me has been a rarity in close to 40 years in the field…

Greg Jorgensen on 11 February 2014 at 6:25 am

@Scrum Master: You’re agreeing with me. If a Scrum project works it’s because the Scrum Master has the management and communication skills required to focus the team, reign in personalities and egos, deal with management, and “promote a common vision.”

Someone with those skills can lead a successful project using almost any methodology.

I don’t mean to insult your skills or training, but you must know that it’s pretty easy to get certified as a Scrum Master. I’ve attended Scrum training, I’ve worked with several Scrum Masters on different projects. Those projects succeeded or failed because of the team, not because of Scrum. Using Scrum techniques can certainly help a functional team succeed, but it can’t help a dysfunctional team not fail.

l&S on 11 February 2014 at 6:29 am

@Ricki….that,s true….i to use that though am new in the software developing world.

Greg Jorgensen on 11 February 2014 at 6:33 am

@Steve Naidamast Completely agree. Even so-called RAD and Agile projects have a BDUF because that’s what management is comfortable with. The design may not be detailed or thought through very well, and it may be dribbled out to the developers bit by bit.

That’s been my experience with most Agile projects: the team is not discovering requirements or working from use cases — they are just getting requirements spoon-fed to them so they “don’t worry” about the big picture and get distracted.

I’ve worked on both BDUF/waterfall and agile (small a) projects that succeeded. Looking back on those projects I remember the people and the conceptual integrity, not the process.

Winston on 11 February 2014 at 6:36 am

My first real experience in a “team” environment came in my 15th year of programming – I’m now in my 40th if that means anything. I was looking forward to some actual design specs to work from and a common goal. Those illusions were dashed within a few weeks. My indie experience – considered a negative during the interview process for that job – proved to be my best asset, i.e. being able to do a major makeover on short notice, and being able to deal with huge shifts in the scope and direction of the project and taking it all in stride. As well as keeping a wary eye on a part of the project and the incompetent that was working on it, and preparing myself to take it over when that person inevitably quit or was fired. He did, and I did. My cynicism about the methodology was at first considered “negativity”, but then later elevated to prophetic genius when all of my predictions about release dates etc. came true. As if someone’s a genius for saying it will rain in Seattle. I’m convinced programmers as a group fit the definition of insanity: doing the same thing over and over expecting different results. Oh the methodologies are different, but the “this time we’re going to use a methodology and make it work” mantra never dies.

When the last vestiges of the original Gantt chart lie smoldering in ruins, that’s when it’s time for me to get to work. I’m in my element. And I’ve never had to personally torch the chart to get there. They have a habit of spontaneously combusting, usually rotting from the inside out but sometimes a spectacular flare-up that scares the crap out of everyone from top to bottom. For many, it’s the end of their world. For me, it’s freedom.

John Keklak on 11 February 2014 at 6:47 am

No doubt most would agree that software development is mostly “research”. @Greg Jorgensen Even most of your work fixing web site code consists of research. To have even half a chance of estimating rationally, it is necessary to first accept the research nature of software development.

See Chapter 3 of “Introduction to Software Development”: http://bit.ly/M8wxS1 (pardon the rough state of the text; it is currently only a draft version)

@KevB @Greg Jorgensen It seems we also need another word for ‘technology’.

Anon on 11 February 2014 at 6:51 am

Agile is no more and no less than anthropomorphic observation of the human behaviour capable of producing good results. It does not show you how to get it. It just gives you the awareness to recognise the processes and people behaviours you are likely to find in a well functioning group of people. if you happen to be in one or see one take note and think yourself lucky.

Greg Jorgensen on 11 February 2014 at 6:57 am

@Winston Thank you — you said it better than I could but I know exactly what you’re talking about.

Captain Kirk on 11 February 2014 at 7:23 am

While I started in the 80s as a Cowboy Programmer, I think I have seen most of this. It is complicated.

Vision: Knowing what you are building & Why! Clarity: Knowing what you are NOT building. Focus: Having access to the people who will use it and train you in their jobs enough to “get it”.

Then you have Conceptual Integrity (is there a metaphor or elevator pitch maintained by the architect so everyone understands the system will have limitations but strengths as well)

A Clear definition of success (which should include how fast the response times need to be, because I am tired of people finishing a system that takes 30 seconds to add a new record and think it is fine when it is a keypunch type application).

Finally, you need competent people, time to do the right thing, and management to stop picking RANDOM dates.

The toughest part is the schedule, and unless you are building the same widget you have done over and over (or management is willing to spend 30% to get an accurate estimate [see cone of certainty]), having lots of unrealistic deadlines and no ability to get the message to the stake holders is RISKY.

Many years ago, we estimated (rough) that it would take use 2man years of effort to take on a new business line. The owner then counted EVERYONE in the room (6 of us) as full-time developers and concluded that we should be done in 4 months (on top of our existing workload, of course).

I suggested we label everyone in the office a programmer and we could have done tomorrow at noon! Somehow, I was the one being belligerent!!!

There are many places to place the blame, but for me it starts with management not understanding the process.

If a Secretary told her boss that she would 500 pages of hand written notes in 2hrs, he would not believe her.

Yes, a detailed plan of attack, and thorough analysis are required. But that should be DONE BEFORE the project actually starts! I find too many companies consider ALL of that to be part of the project, and they want the ESTIMATE first (with a target they already have in mind, and no limits to what they will ask for, of course).

I feel the world has gone mad. The places that succeed often control the definition of success (MSFT ships offices with HUNDREDS of unfixed bugs)

Arun Sunny on 11 February 2014 at 7:41 am

Good post .The comments made by experinced professionals are rather more informative

bob on 11 February 2014 at 8:14 am

We use BDUF where I work, and I too get the feeling of working on a team where everyone clicks and things just get done. That’s not to say it’s completely fault-free. The designer and project lead spend hours each week in design meetings, hammering out one page at a time which gets sent down to the development team. Even so, we often get those pages done in time with the designer and work gets done at a quick pace. Another instance of BDUF failing to deliver is when the development team and when the designer were not in agreement on how to structure pages on a site and we had to restructure the website. Luckily, this happened early in the process so it didn’t cost too much in terms of time, but it was a learning experience.

We are looking at ways to improve the process, but that leads me to think that something like BDUF should just be looked at as a template. Once you start working with your team you tune the process, adding what works and removing what doesn’t work.

araybould on 11 February 2014 at 8:42 am

Methodologies don’t deliver the results their adherents expect because their expectations are based on a fundamental misunderstanding of software development: it is not a form of manufacturing, where the goal is to produce many replicas of the production prototype, it is a design-like activity which concludes with the creation of the production prototype. Success depends on knowledge and good judgement, and methodologies cannot substitute for this; at best they provide guidelines for competent people.

Mark on 11 February 2014 at 8:51 am

Wonderful vindication of DeMarco & Lister’s “Peopleware” (1987).

Dan Sutton on 11 February 2014 at 8:53 am

Absolutely right. Another way to look at it is like this: just as one should work out what the problem is before choosing a language in which to write the solution, the same goes for the development method: as you say, no one method suits any problem: to choose a development method irrespectively of what you have to solve is just as idiotic.

There’s something more, though: in many cases, these potted methodologies do little more than shield the incapable from detection: as someone who’s been programming since the ’70s, you’re no doubt as aware as me that most of today’s programmers simply don’t understand the basics — they run around spouting acronyms and “leveraging functionality” – whatever the hell that means – but they can’t write a simple sort algorithm: “There’s a class for that”… so, from that point of view, the best development methodology is education.

BrainiacV on 11 February 2014 at 8:53 am

I agree with everything you said, and many of the comments.

I’ve always seen “methodology” as a way everyone (mostly management) to turn off their brains and think the process will guarantee results instead of the efforts of the team.

It’s what I call “Industrial Age Thinking” as opposed to “Information Age Thinking”. Industrial processes are based on the idea that you can come up with the ideal way to manufacture widgets through design and/or time/motion studies.

That doesn’t apply to software development. Programming is driven by cognition and you can’t force everyone to understand everything at the same time or degree.

You can try to make things easier, but there is no guarantee what you do this time will work the next.

Which is why I view software development like jazz, you go with what works at the moment.

robb on 11 February 2014 at 9:15 am

Very thought-provoking article. IMO, it comes down to this: People, process, tools….in that order. Without the right people, any process is worthless. With the right people, it can help alot.

James Ashley on 11 February 2014 at 11:24 am

Why don’t software methodologies work?

Because you aren’t doing it right and nobody else is either?

The saddest thing is when even the people implementing an agile process have no real faith in it. I had a project where SCRUM was done off of a visual studio template and after about three weeks no one was even adding stories or moving cards anymore — and worse, no one seemed to care. They still extolled the virtues of git over TFS, tho.

Oh — and the project took twice the time projected, went way over budget, functionality was cut, people were thrown under the bus (including most of the design team) and, it turned out, the iOS expert leading a big portion of the project didn’t actually know how to build iOS apps, etc. Good times.

Thomas Phaneuf on 11 February 2014 at 12:03 pm

Good article. And I agree with the author and most of the comments. Any methodology (yes, more accurately, “method”) should be looked at as a prospective path, not a silver bullet. It can’t replace the overall vision, or the compensate for problems with people in a development team, or address all the unknowns or even make coffee. But it is a starting point. It can also help guide the development and help keep it moving towards a goal. Methodologies, if used right, are a good thing – but not magic, and not a guarantee. However, if there is more focus on the development method used than the project itself, then things will go awry very quickly.

I like what Topher wrote and it is worth stealing and repeating:

1. Get the smallest number of the smartest people possible together.
2. Give them a clear goal.
3. Get out of the way.

Andrej on 11 February 2014 at 12:55 pm

Non professionals + Good Methodology = fail

Non experienced team of construction workers will not build a skyscraper

WyattMobile.com on 11 February 2014 at 2:09 pm

All Software Methodologies are a desperate attempt to include stupid people in the game. From SCRUM to TQM, they are all an attempt to allow someone with a communications degree to be included. Those people are cheap to employ, and owners are convinced it is a matter of having enough idiots who can tell a programmer what to do.

Cassandra Andra on 11 February 2014 at 4:24 pm

Claro! Animated cartoons often depict a group of IT planners gathered around a blackboard with arrowed lines drawn in every direction, criss-crossing dotted lines and unfathomable schematics, meaning haplessly confused. How to create more content over time is a driving function of the world. Even this example generates five seconds of entertainment!

Though I don’t think the purpose is to include poorer programmers in the game, I rather think it is to create a sideshow. It’s something else that can be “done” and therefore is. Short of the sense to not destroy the world, “do override” is major problem in the logic of the mind. A better law would be, “A system at rest should be left to rest.”

Most people in a room empty except for a button, would push it. Then, a bouncing ball in the same room would inevitably push it. I agree, it’s just one more thing that IT persons can do – is philosophize about work. Hmm…

Matt on 11 February 2014 at 4:27 pm

I’ve been a developer for 20+ years. Like the author I’ve seen all the methodologies and lots worked / failed in many different situations.

The one common thing I’ve noticed is the owners (managers, stakeholders etc) do not know how to document what they want or don’t really even know what they want.

I’ve started using a few simple diagrams that I borrowed from a book called ICONIX by Doug Rosenberg. I found that these simple diagrams (Use case, Domain Diagram, Robustness) were all I needed to bridge the huge gap.

It gave us all a common nomenclature (domain diagram) it helped managers quantify the invisible (like when we’re working on things they can’t see, like databases, views, procedures, functions, etc) it helped us to estimate (count the bubbles and multiple by some coefficient)

It forced project owners to do more than draw up a screen in photoshop and then believe that since they can see it it must be really easy to build. It also forced them to think about what they are asking so that they don’t make illogical or contradictory requests.

So, no matter which methodology, increased communication of what the software should do, not how it should do it, and the god forsaken question “how many hours is that going to take” have always been signs of success for me in my career.

Good developers self monitor and don’t need a stupid scrum meeting daily.

Peace,

-Matt

David Slick on 11 February 2014 at 9:19 pm

Your thoughts definitely resonate. Particularly the fact that there’s not one silver bullet. All too often “Agile” is used as just that, a silver bullet to solve other problems deeply embedded in the company culture/leadership. Agile doesn’t solve those problems, but I’ve seen it help shed light on them so they can be fixed. But it still takes mature teams/orgs to do something about them. It also enables you to get customer feedback and integrate that so you can adapt to build things incrementally toward your ultimate value goals, but it takes a company that has customers and is willing/able to access them.

Also, I’ve seen great code written using TDD and without any unit tests. But on average, the code I’ve seen unit tested is of higher quality, if TDD’d even better, and it mostly stays working over time.

I think it’s important to be clear about any methodology is meant to give you. Do you need that? Are you willing to pay the costs associated to get it? Is it worth it? Do you have teams mature enough to handle it? Do you have management skilled enough to deal with the output?

And more importantly than the practices, agile is about the values. You share those values outlines in the agile manifesto? If not, don’t bother, you’re just wasting your time.

Stephan Schmidt on 12 February 2014 at 12:07 am

“rigorous studies of software development methodologies haven’t been done because it’s impossible to control for all of the variables.”

No, because it’s so much easier to go by anecdotes than do some multi-year research on a topic.

Greg Jorgensen on 12 February 2014 at 4:29 am

@Stephan Schmidt: Maybe “easier” to go by anecdotes, but when you can’t control for the biggest variable — people — it’s not possible to test the effectiveness of a methodology. There’s no way to have the same team do the same programming task using different methodologies and from that determine which works best, unless you have a Men In Black memory eraser.

Edub on 12 February 2014 at 8:20 am

“Once a programming team has adopted a methodology it’s almost inevitable that a few members of the team, or maybe just one bully, will demand strict adherence and turn it into a religion. The resulting passive-aggression kills productivity faster than any methodology or technology decision.” Excellent point!!! So, So very true!!! I have been subject to the bullying of system engineers and DBAs who seem to base their adherence of a “policy” based on how they feel that day. Policy is in quotes because either they have never read the policy (just hear say) or in absence of a policy they make up their own rules.

Tim on 12 February 2014 at 1:15 pm

#4 Fred Zisk: “The only method that seems to work is waterfall.”

Having completed well over a dozen implementations of enterprise systems in the last decade, I can say with complete confidence that waterfall is a project killer. There indeed is no silver bullet but Agile comes the closest to acknowledging the realities of modern business.

Tom on 12 February 2014 at 2:49 pm

Would you ask a biology graduate to remove your appendix? Would you travel in a jet plane designed by a team of mathematicians? Would you work in a chemical plant designed by chemistry grads. Wonder why the development processes don’t yield better results? Just look at the people.

Roughly half of all software developers have degrees in computer science. Most of the rest do not have degrees related to computing. I did some work for a government agency and discovered that one developer had a masters in Eastern European folk dancing. Hopefully he minored in Java or something similar.

Training shows you how to do something while education broadens your mind.

The people who graduated in physics or math have some change, but even the people who graduated from Computer Science were educated by the Science Faculty. The Science faculty does not train people in product development. There are no courses in development metrics, configuration management, project management or quality assurance. Basically the vast majority of the people producing software today were never prepared for this role by their education. They are essentially all self taught.

And they do not know what they do not know!!!!

As for the methodologies that do not work, I have very seldom seen an accurate description of the so called waterfall model. Advocates of other methods us it as a straw man to show how much more reasonable their approach is. But the waterfall model just says requirements before design, design before construction, construction before testing. All engineering processes follow this model at some level (although the TDD people seem to want to reverse this). Basically, most of the people involved in software development have not really studied any development approaches and most groups adopt a given method as the result of the preference of the loudest person in the group.

Another really bad thing about most software development processes that are actually in use is that they are oriented towards building features. While that is what users are interested in, it is not what engineers produce. Engineers produce designs for things which is software translates into components. In a feature oriented development, anyone can change anything which typically forces code merges and the associated defects that merging introduces. It also forces everyone to be familiar with everything which is okay if the system is 10,000 lines of code but is a disaster when the system is 500KLOCs or bigger. Nobody can understand enough of such a large system to safely make modifications to arbitrary parts of it. And if everyone is responsible for all of the designs of all of the changes they make to all of the bits they touch to implement their assigned features, nobody is accountable when there is no design.

Failure is not left to chance. And even when a project fails, it is often deemed a success. Look that the Chrysler c3 payroll project that gave us agile development.

initdotd on 12 February 2014 at 7:06 pm

One word, plastics! All kidding aside the common vision is critical. As it develops and the truth begins to show itself, you end up with, regardless of what you call it, requirements. Idea to concept to something well defined that indeed can be measured and deemed success when reached. Methodology has nothing to do with finding the truth although some would argue it helps you get there. I’ll buy that. The point is you learn as you go and what you measure as success will directly impact the way you choose to define it.

Rick Mowen on 12 February 2014 at 9:48 pm

Yes – I heartily concur with this interesting treatise on the fundamental nature of practices in the area of software development postulated by this intriquing author. I myself have developed several similar methodologies. My first foray into this area led me to develop “yum-go-go” a work framework which simply states that the relative work accomplished is directly proportional to the size of one’s breakfast. It was adopted throughout the many large organizations and led directly to the implementation of work sponsored cafeterias. Having worked mostly at smaller companies, I never did directly benefit from those advancements which led me to develop over time “obscure-o”, which postulates that the amount of equipment one’s office, working or otherwise, is directly proportional to one’s worth as a team member. Lastly, my hobby as a collector of Americana, as well as my involvement in Linux (which I pronounce Lin-ish as a tribute to my own personal involvement in the erstwhile os), has given me the perspective to write “Working Without Effectivity” which is an explorations into the field of “Malleable Task Management using Waterwings”.

Keep up the good work!!

A Scrum Master on 13 February 2014 at 1:26 am

@Greg Oh yes, I’m not arguing that you don’t need a well-cooperating team, or that process would be more important than the people on the team finding that spirit and “clicking”, as you put it. I was just surprised that you dismiss the agile / Scrum approach on that basis, since from my perspective that’s exactly what they’re about. As someone else pointed out above, after all the first sentence of the Agile Manifesto is “Individuals and interactions over processes and tools”. Isn’t that also what you are saying?

And of course anyone can take a two day seminar and get a Scrum Master certificate. But I find it hard to imagine that within those two days, you would not speak about group dynamics, about Tuckman’s stages of group development, about handling “difficult” people, about how team members have different expectations and motivation, about retrospectives and how to make them effective, and how to set an atmosphere where everybody speak their mind. I’m not saying that you are given solutions for all of those challenges, or that everything then subsequently just works, but at least you’ll have some awareness of these issues.

Which brings me to my last point: Those projects you mention you are involved in routinely, those where “almost nothing of real value is produced” – are Scrum projects among those? If one of these projects was a Scrum project, how did the Scrum Master handle the situation? When nothing of real value was produced, clearly there must have been sprints where the sprint goals where not reached. It’s hard to imagine that the Scrum Master wouldn’t address that at all. Was the burden of too much process etc. never brought up in a retrospective? Being agile is about adjusting the process – you sprint, find out what went well and what went badly, encourage the former and try to reduce the latter. If in your project things didn’t work out and you just kept doing them anyway, well, then that wasn’t really an agile approach, no matter what your managers might have called it.

I really think most of what you write is correct, but the headline for me just isn’t. “Why is everything that has been found out about collaborative software development in the last 20 years being ignored in the projects I work in?” would be a more appropriate, if less catchy, title.

Alessandro Koterle on 13 February 2014 at 3:19 am

After having thought it over for a while before leaving a comment, it came clear enough to me that this article is lacking too much in giving clear boundaries and contexts and then it could be likely misleading. Indeed, seems that even the author has recognized it and retreat a bit by editing original post which lead me to consider this article more seriously. Having been worked for many years on many small/big projects, with huge teams, adopting any of existing methods, processes, practices, technologies doesn’t necessarily mean having got them right or at least not giving them enough attention. Claiming that no methodology works is like saying ‘No girl/boy-friend is good enough for me’ should I live alone then? or ‘None of any car is suitable for me’ should I walk a lot then? or ‘None of programming languages fit my expectations’ should I learn and use them all together ? (guessing whether learning well enough more than ten could be actually possible).

Furthermore, should we all discuss on a mix of several relevant topics such TDD, OOP, Agile, RAD, Scrum, Human interaction all at once in an misleading if not erroneously ordered unlikely recipe?

More than that, reading the article, I have personally perceived that it is mainly focused on people ant that leads me to to think how often people run into troubles with his peers (job mates). Please note that Alistair Cockburn thesis reports several answers we all could further discuss on and not just keep them as a generic and ‘pessimistic’ conclusion over human beings. Indeed he also answers that: “Every project needs a slightly different methodology, based on those people characteristics, the project’s specific priorities, and the technologies being used. This result indicates that a team’s methodology should be personalized to the team during the project and may even change during the project.” So he is saying something slightly different from what this article aims to.

I perfectly agree on ‘Strict Management’ issues, on ‘No Silver Bullet’ concept and on what ‘Two-different-programmer-teams’ thought experiment aimed to claim at and also that human beings personalities and interactions obviously will ever make the difference. People interaction over processes is another good point I agree upon.

But there is a quite big discrepancy between arguing on such issues and claiming that most of or even all methodologies will fail. Furthermore, who or what will exactly fail? How long a project should last before stating a given process/methodology makes it fail? Who or what lead the change in adopting a new process or methodology and who or what actually caused the failure?

Scrum has been mentioned as well. Scrum is not a methodology but rather a framework providing teams with some guidance in adopting proven ‘agile’ practices. It’s up to managers, software development teams, hardware teams, even sales get a try and work hard to achieve continuous improvements.

Here we go, Is the continuous improvement a ‘typical programmer’ aims at?

Mr CSharp on 13 February 2014 at 1:05 pm

I agree with this blog on the most part. No one methodology works alone. You got to take the best of every methodology and adapt as the situation comes along. Definitely some methodology and standards are better than none. The thing you’d hate the most, especially on a mid to large sized teams is when you have numerous code achieving the same functionality and that similar code is copied and pasted everywhere. Then, when the functionality changes, multiple code changes are required throughout the app. That’s what you call cowboy programming. Methodology and standards that are too strict definitely kills the spirit on a team level since rules cannot be bent to allow for flexibility. Think of it this way, software development is like the Matrix. The Matrix keeps everything in-bounds, which is a good thing. The Matrix can also warp to adjust for other things and it’s not rigid. The Matrix is your friend in the software world, unlike the movie where it is the enemy. 🙂

Gnum on 13 February 2014 at 2:35 pm

All you saying is the rephrase of the old statement – “Any system is only as good as it’s parts combined”. Of course no method can substitute the actual skills, effort and genuine commitment. You can’t expect to take a bunch of sloppy inexperienced, willing to work for a higher salary, workers, call them developers and with the magic of some Methodology produce good software in short time for small cost. Of course you need to have an adequate skills and sufficient level of commitment in a first place. This is all only a premise for methodology.

Methodology comes to play when you DO have a good team with good skills, well committed, with right attitude and sufficient social skills. When you have all that then you have a choice of how exactly you organize your work, and then it comes to the choice of pattern and the process.

Saying there is no need of pattern or the process is effectively saying that the team is either not in a state when it is ready for any organized work. In other words it means you don’t have a team. You have some may be well talented individuals, may be even in the same room, but that doesn’t make them a team.

Until you have a qualified team the question of methodology or the process is an abstract. It is like choosing the route of commute before getting the job. It doesn’t matter which way you come to work of you don’t have a job. It doesn’t matter how you dress for work if you don’t have a job. It doesn’t matter what you decide your daily work routine to be if you don’t have a job. None of these choice will make any difference on your income if you don’t have a job.

Same story with the process, methodology and the team. If you don’t have a functional team – no process will help. When you do have a team – the choice of methodology and the process will make a whole world of difference then.

Gene on 13 February 2014 at 9:13 pm

I had to weigh in on this excellent article. As said directly above, the comments made by the experienced professionals are of more value than the others but it is good to see technical professionals debating this subject.

I coded, then project managed, then directed but when you have your own business and it is really your money that is being lost and your firm’s name that is at risk with your customers, the learning curve steepens. Following are a few things I’ve learned and some quick thoughts on the matter.

Clearly no one methodology fits all projects. I have a lot of trouble listening to individuals who think one method is the best (sometimes the only) solution. The overall approach must fit the type of project, type and criticality of the application(s), complexity, timeline, acceptable level of risk, customer’s team, customer’s business controls, technology team’s familiarity in the application area, available tools, diversity in the team, customer’s maturity with the process, the team’s professional maturity, acceptability of frank and open challenges in the various environments, communication skills among the members, experience the team has with each other, proximity and access the team has to each other and all the various constraints whether technical or project oriented. I’m not being glib here making this list. This was just a quick flow and is not organized but if you really dig into projects you will see that every one of these things and more factor into the equation.

This is why each project should start with an approach yet remain flexible as more is learned about all of the above. Long academic debates about waterfall vs. agile are interesting and much can be learned, but at the end of the day a general approach needs to be determined and then some principles developed to control the project.

Principles allow the project to be controlled as tightly or as loosely as fits the overall landscape. For example a principle may state “no code shall be final-tested by the same individual that did the programming” and “subject matter experts shall control the final testing” and “subject matter experts shall be named and will formally have defined functional responsibilities”. Obviously much care must be taken developing and applying the principles and they must be comprehensive but statements like these are easy for everyone on the team to understand and it is easy to measure compliance. And principles can be loosened up to be more of “guidelines” or tightened down to be more of a “specification”.

So after my 30+ years at this on projects small and large and in some very critical environments I have come to the same conclusion a neurosurgeon who was my doctor told me one time “the more experienced I get the more I realize the less I really understand”. The key word is understand because certainly the experienced professional knows more than the less experienced, but how much is really understood of a complex subject as this, with humans as the primary variable, is the elusive part which really matters. So my conclusion is to start with the best approach you can given the experience level in your team, consider using principles you develop instead of very rigid structures, encourage debate and be willing to listen, learn and adapt but keep the eye on the goal. Most importantly keep moving forward without dwelling too intently on trying to control every element of the process. Oh and the obvious hire and provide motivation at all levels for the very best people you can afford!

Stefan on 14 February 2014 at 12:56 am

I’ve found that all software processes have two things in common:

1. plan your development in managable chunks, over managable intervals of time
2. reassess your achievements in regular intervals and adapt your assignments accordingly

The projects that were good at these two things also went reasonable well. Those that didn’t went way over budget or failed. That said, I recall only one case of failing at the first 😉

Piotr on 14 February 2014 at 2:44 am

The answer is easy – the “problem” is not because of methodology, the “problem” is because of skills… New methodologies are invented to “legitimate” lame development instead of facing the issue directly – poore skills. Really good developer can be successful even with waterfall up-side-down or whatever. The thing is that education is tough, requires lots of effort and time, so it’s being skipped in our greedy world.

H.M.Müller on 14 February 2014 at 7:20 am

All “engineering” (design-level engineering) works like that .. what’s “the problem”? Talk to people designing (not building!!) a next generation car engine; or an airport (even a small one); or a new assembly line. We always go to the limit of what is possible – that’s the whole idea of that “progress enterprise” mankind has been doing at least for the last 400 years.

All teams I have worked with in the last 30 years have used methodologies – i.e. abstract ideas about how work (thinking, designing, communicating, writing code, testing, etc.etc.) should be done: They had their rules – sometimes purely local ones, but most of the time a mix of external and local ones they adapted – knowingly or unknowingly – to their environment. And they worked to the level they worked – depending on the environment (much/little money, much little/time, good/bad managers, …) and the problem to be solved (standard/risky, large/small, …).

This article shows once again that programmers (me included, in my younger years) are a bunch of people that believe that they can rule the world with what they think. This is simply wrong. But of course it is still worthwhile to try to organize oneself and the people around – from team to project/department to all stakeholders – so that the enterprises we start come to an end that is as good as possible (measured on that very multi-dimensional scale of “good”*).

• There are even projects where it is a success if they fail … I could tell a few stories about that.

H.M.

Tim S. on 14 February 2014 at 1:03 pm

Definitely agree. This was one of the best programming articles I’ve read in a long time. I’m sharing this with my-workers as our management is looking to implement stricter red-tape/processes in our environment, even though all is well.

CMS on 14 February 2014 at 11:36 pm

I agree it comes down to the talent. The “not reverting to cowboy coding…” comment grabbed my attention the most. My initial reaction was skepticism and admittedly some disdain. However, who am I to question your life’s experience.

My reaction stems from the following. There are oceans of garbage development in the industrial automation business. Which I believe is a somewhat different craft, but surely shares many fundamentals. Per my life experience most of the people I’ve run into that deride specs, processes, documentation, meetings, etc. often do the worst quality work, AND can’t see it! And even when forced into more structured work processes, it only helps so much, because the values still don’t match.

So I come back to my opening, the talent, and good leaders/mentors are the most important part of project success.

I shouldn’t complain about bad coders, they are good for business in our arena. But it disheartening at times being immersed in rotten systems all the time.

ricky on 15 February 2014 at 3:15 pm

You left out an interesting if expensive option that I’ve seen work. Plan to throw one away: In particular, first build a BDUF thingy a as a prototype; Document the hell out of every function and module; Use the documents and running code as spec for the next version.

Andy on 16 February 2014 at 2:44 pm

IT Consultants can take much of the blame for corrupting methodologies. It is often…no always in their interests to pad out a project with extra staff, extra process and to take as long as possible. Their version of “good practice” is all about profit…and it works depressingly well.

I have seen $800M spent on a data warehouse that was designed to fail. (raw XML in relational tables with one column!) 80% of the “team” had never coded yet they were convinced they were “high level” design geniuses. I can design a nuclear power plant at a “high level” and it is similarly useful!

Why is all this failure and waste not reported? The ones who hire them cover their reputations and call the project a “success” then claim their bonus.

EG. A large Telco spent over a decade trying to get a “flexible” billing system to work…they gave up and hired the same consultancy to replace it with a new one. This seemed baffling until you realise how the “alumni” system works: You scratch their back…

IT is productive, it creates wealth. Like leeches to a bloated swimmer, the consultants and pretenders tap into the wealth. Programmers are now beast of burden, to be tapped and carefully contained by the ladder climbers and pseudo-techs.

Jacek Dalkowski on 17 February 2014 at 3:20 pm

Best methodology is good will and common sense. Unfortunatelly, it is not popular enough 😉

Phil W on 18 February 2014 at 11:29 am

That opening paragraph nails it – in decades of programming that has become the problem. There’s a hole in the hierarchy between the managers who say “We want this” and the developers. The middle guys who could translate requirements into development strategy, plans, code, objects or whatever (the Powerpoint to coding guys) have gone. I think managers were never happy about their technical objections or their salaries after years in the business, so a bunch of largely clueless programmers beneath a manager who can’t actually guide them technically has become the norm. I keep seeing this in many setups and the results are as predictable as you’d expect, regardless of methodology or tools.

Daniel Garcia on 18 February 2014 at 7:21 pm

“I think programmers should pay much more attention to listening to and working with their peers than to rituals and tools” Do you think pair-programming could help in some degree to “work with peers”? Just curious to know your opinion.

nooshin on 19 February 2014 at 1:52 pm

hi,I’m doing a project and I need information about the software engineering methodology developed in 20 of the last 50 years to know please help me in this regard

Brian Shreeves on 2 April 2014 at 7:09 pm

Greg, I realize this post is not old, but chances are your experiences have a little more mileage. Considering that you have realized that personalities, teamanship and proper leadership are crucial to the success of a methodology, therefore the product. Have you recognized ways to aptly put together a well functioning team?

John Hunter on 23 August 2014 at 6:10 am

I think the key bit there is “in and of themselves.” Certain methodologies are excellent in the right situation. But I do believe things need to be molded to the organization.

I do think agile-like methodologies are very good for most (if not nearly all) situations. But different situations will require somewhat (to very) different practices within the agile range of options. I wrote about my experience

http://management.curiouscatblog.net/2014/05/29/building-a-great-software-development-team/

Erin Shellman on 26 August 2014 at 7:02 pm

I wonder if maybe you had that feeling of conceptual integrity in the bad old days because people don’t stay in their jobs very long anymore. With such high turnover it’s got to be hard to really develop a high-functioning, super productive team.

Gregory McIntyre on 26 August 2014 at 7:03 pm

I agree.

Question: Is agile not meant to be taken with a grain of salt and applied wisely and perhaps adaptively to the circumstances at hand?

If you read the agile manifesto, that seems to be the implication. Perhaps it’s the eroding of the original spirit as larger corporations adopt a top-down authoritarian approach to agile that goes against the entire point of it, that agile becomes silly.

Doug Reeder on 27 August 2014 at 7:00 am

I’d say, rather, that the real goal is something beyond process that we can’t yet describe. The goal of any process is to get programmers in the state of mind where they write good code.

Isidro López on 27 August 2014 at 10:21 am

The point is: would two IDENTICAL teams within IDENTICAL conditions get the same results with a waterfall and with an “agile” methodology?

When I say “the same results” I’m thinking about everything: the quality of the code, the satisfaction of the customer, the satisfaction of the team itself, the economical cost, the duration, etc.

Obviously, it’s scientifically impossible to prove it (because two things can not happen at the same time… I think 🙂 ), but all the experiences that I had myself and saw around scream out the same answer: NO. I would definitely bet my own life that the overall outcome would be mucho more satisfactory following agile-like methodologies rather than waterfall ones.

Oh, sure, I forgot to write down “IMHO” at the very beginning of every sentence that I wrote :-p