GROWS logo

In no particular order, here are the four essential parts of a successful, modern software development strategy.

  1. Impeccable, reliable, automated build and deployment system.
  2. Tight team integration and effective collaboration.
  3. Constant learning and skills improvement.
  4. Design and architecture based on Functional Programming concepts.

The first two are pretty much uncontroversial, but we’ll go over those first just to make sure that we’re talking about the same thing. The third one is an obvious but often unspoken truth, and the last is the culmination of a long-brewing idea that I think makes perfect sense once you see it.

Let’s take a look.

Rely on Continuous, Automated Builds

No matter how skilled you are at working with your users, inventing awesome new interfaces, coming up with great ideas, elegant designs and architecture and more – if you can’t reliably build and deploy the software you might as well not bother writing it at all.

Collaborate Effectively

Teams, executives, users. We all have to figure out a way to work together, and that can be hard as all these groups have different agendas, different requirements, different skill sets, different values, and different viewpoints.

So let’s start at the top. Regardless of the details of any disagreement on technology, schedule, staffing, etc., the first question to ask is some variation of, “what’s the point?”

In other words, what is the ultimate corporate vision we are trying to serve?

Learning Constantly

The only defense against constant change is constant learning.

But there’s more to “learning” than just cramming in an API to the latest JavaScript framework. You have to “unlearn” almost as much as you learn. This is one of the things that throws people who are trying to learn a new development methodology, or learn a new programming language paradigm (e.g., from procedural to object oriented to functional). You have to throw out the old habits, the old mental maps, the old problems solving approaches because all of those things are different now.

And yes, it’s constant. Never ends. It’s not restricted to just new and emerging technologies, either. Change can come from everywhere:

  • Audience and markets
  • The evolving system under construction
  • Users growing realization of their needs and requirements as they learn them
  • Technology details (this framework vs. that)
  • Paradigms (SQL vs NoSQL, OO vs FP, MVC and variants)
  • Increases in your own skills and abilities

Apply Functional Programming Concepts

The growth of Functional Programming languages and approaches at the moment is heartening; FP represents yet another fundamental way of thinking and reasoning about software design and construction. As with the shift from Procedural to Object-Oriented Programming Systems (OOPS), the shift from either of those to FP is pretty fundamental.

OOP sounded like a great idea at the time, and perhaps implemented purely it might have been, but as commonly adopted we did a very bad thing.

Mutable state, temporally coupled and diffused throughout the system, in a tangled, spaghetti bowl of mud. With OO meatballs.

Instead, FP can be thought of looking at a program as a series of transforms on data. Like a pipeline.

-> O -> O -> O -> O

Each step – each function – is stateless, with no hidden timebombs or surprises. In contrast, in many OO programs, each object is sitting out there with a a hidden grudge against the system, ready to pounce and wreak havoc when you least expect it.

WIth a series of transforms, like a pipeline, it becomes much easier to test and reason about what the software is doing, and more importantly, what’s up when something goes wrong. Its much easier to pinpoint the location of the problem and solve it.

But it’s not just testing, it’s about replaceability. It’s about disposable software.

When a component – a step of a pipeline, a function – is suddenly and unexpected made out of date, it should be easy to rip out and replace with something else. The pipeline approach lets you do that easily.

tracer bullet development, which we’ve suggested ever since TPP, fits in nicely to this idea.

Made the initial TBD a pipeline – stateless, immutable.

Graduate from their to immutable infrastructure.

Now you can replace anything that needs replacing easily, and onfidentally, backed up by some tests, with no time bombs or surprises.

  • Functional, immutable design – immutable data, immutable deployment. DRY.
  • Think of it as a pipeline (e.g. Unix). Disposable parts.

Disposable software

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use The GROWS Method™. We will not use your email for any other purpose.