Reinventing the Wheel Considered Useful

We, programmers, are prone to reinvent the wheel—for example, by creating frameworks and libraries instead of using existing ones (very common), or even write our own build tools from scratch (less common).

We do that despite paying lip service to the fact that reinventing the wheel is generally considered a bad thing. In fact, conventional wisdom says that, from a business point of view, reinventing the wheel can be very expensive—developers spend time both to create and to maintain artefacts that could be bought instead—and, from a technical point of view, using a third party product often means fewer bugs to take care of and less time spent doing maintenance.

I used to think that as well. Not anymore. Recently—after giving some references to some widely available good quality ones—I’ve even found myself suggesting a client to keep their in-house C++ unit testing framework if they wanted to. I did that for two reasons: first, it wasn’t a drag on the project; second, I was pretty sure the team had some form of emotional attachment to it and I wanted to keep them. Forcing them to use something else would have probably upset them and made them less productive as a result.

In fact, I’m convinced that allowing a small amount of wheel reinvention in a project has some advantages: it is a cure against boredom, a booster for happiness and motivation, and a way to learn new things. The increased happiness, motivation and the new learnings will improve productivity which, in turn, will help in recovering the associated costs.

During my career, every single team I worked with had reinvented the wheel at least once and, every time, without exception, the programmers who did that were quite proud of their creation and they spent quite a bit of time to improve it. That also gave them something to look forward to, both when the projects were experiencing difficult times, and also when the times where boring and uninteresting—often, when things go very smoothly for a long time, and the technical challenges are few and far between, boredom kicks in and the developers may struggle to stay interested and motivated.

Good programmers are curious by nature and always want to understand how things work, therefore reinventing the wheel can be a great learning experience. For example, writing your own unit testing framework (as many of us did) is a very good way to understand better how that kind of frameworks work, and to understand better the reasons for some of the choices made by the creators of famous ones ones like JUnit, CppUnit, etc. The same can be said of any other frameworks.

A final word of caution. If the amount of wheel reinvention is too much, the project may sink—costs as well as delivery times will go up, and the people in the team may find themselves spending too much time doing infrastructure work and not enough in adding value for the other stakeholders—so you will have to find the right amount for your projects.

Methodology à La Carte

à la carte |ˌä lä ˈkärt, lə|
adjective
(of a menu or restaurant) listing or serving food that can be ordered as separate items, rather than part of a set meal.

I’ve been uncomfortable with the mainstream discussions about software methodology for quite some time. It seems to me that far too many, in the software development community, are in a wrongheaded quest to find The Methodology that will solve all our software development sorrows.

So far we’ve had (just to mention some popular ones): Waterfall, Spiral, Evo, RUP, DSDM, FDD, XP, Scrum, Kanban, Disciplined Agile Delivery; and also some cross-breeds, e.g., Scrum + XP, Scrumban (Scrum + Kanban), etc.

We keep finding that each of those methodologies has many strengths, but also several weaknesses that make each of them applicable in some contexts but not, easily, in others. I think this will always be the case.

Let me explain.

Let’s first look at what a methodology is. The definition I like the most is this one by Alistair Cockburn, found in [1]

Your ”methodology“ is everything you regularly do to get your software out. It includes who you hire, what you hire them for, how they work together, what they produce, and how they share. It is the combined job descriptions, procedures, and conventions of everyone on your team. It is the product of your particular ecosystem and is therefore a unique construction of your organization.

According to the definition above, all methodologies in the previous list are more accurately described as methodology frameworks—they impose some constraints, and make some assumptions about the surrounding context, but leave many (important) details to the specific implementations (note that they include team dynamics and personal preferences. They are very important, but I’m going to leave them out for now).

Constraints and assumptions are both a strength and a weakness of every framework. If they are satisfied in the context where the framework is applied, then using the framework can save time, money, and grief. However, if they are not, using the framework can become difficult, if not detrimental.

For example, think of teams working in fixed length iterations that also have to deal with support issues and point releases outside their standard iteration cycle; I’ve encountered this problem several times with different teams, and the implementation of a solution has never been straightforward.

Another example is TDD. I’m a strong advocate of TDD, however, it is a practice that requires some level of proficiency, and, in some contexts, it is just too difficult to adopt straight away. Sometimes it is just better to start by writing unit tests without caring about when they are written—first or last—as long as they are there (and, before you lambast me on this, I know perfectly well that TDD is not only about testing, but also about design; however that’s not my point here).

I can give many more examples, but the point is that, whatever the methodology framework, some of its assumptions and constraints may not be valid in some contexts.

In my opinion, a better approach would be to create a methodology per project by mixing and matching sound practices, processes and tools—which can be borrowed from existing methodologies, or the literature, e.g., [2], [3], [4]—to fit the context and the needs of the project. This is what “à la carte” is about.

Mind you, I am not claiming to have invented or discovered anything—this is what effective teams have always done (and it’s an approach I’ve been promoting for quite some time [5])—but I think that we, as a community, need to have a different kind of discussion from one focused on promoting one methodology over the others.

Some people pointed it out to me that this approach looks like Crystal [4]. I’ve certainly been influenced by it; however what I’m describing here is neither a methodology nor a methodology family (like Crystal Clear and Crystal, respectively), since it doesn’t impose any constraints or assume any context. All it requires is discipline, mindful choices, and the willingness to improve.

That said, I think that there still is a place for methodology frameworks like the ones mentioned before. In fact, you may be in the lucky position where one of them works for you straight out of the box; however, if you are not, and you fear you may incur in some form of analysis paralysis, you can choose one as a starting point, then modify it as necessary—incidentally, this is what many Scrum and Kanban teams seem to be doing anyway.

I’ll be doing more work on this, and I’ll be speaking about methodology à la carte at the upcoming ACCU 2013 conference in Oxford, UK.

In the meantime, I’ll welcome your feedback.


  1. Cockburn, Alistair, Agile Software Development: The Cooperative Game (2nd Edition) (Agile Software Development Series), Addison-Wesley Professional, 2006.

  2. Beck, Kent and Andres, Cynthia, Extreme Programming Explained: Embrace Change (2nd Edition), Addison-Wesley Professional, 2004.

  3. Coplien, James O. and Harrison, Neil B., Organizational Patterns of Agile Software Development, Prentice-Hall, Inc., 2004.

  4. Cockburn, Alistair, Crystal clear a human-powered methodology for small teams, Addison-Wesley Professional, 2004.

  5. Asproni, Giovanni, Fedotov, Alexander and Fernandez, Rodrigo, An Experience Report on Implementing a Custom Agile Methodology on a C++/Python Project, Overload 64, December 2004.

The Never Ending Software Methodology Debate

  1. Start: Waterfall is the mainstream methodology
  2. The mainstream methodology shows some limitations
  3. Somebody proposes a new, or lesser-known, or almost forgotten methodology and shows how it addresses the limitations at step 2 (and how it’s better than Waterfall, of course)
  4. After a long argument, heavily based on personal opinions, and often light on facts, the methodology at step 3 becomes the mainstream one
  5. Go to step 2