PurelyFunctional.tv Newsletter 435: The software crisis

Eric Normand's Newsletter
Software design, functional programming, and software engineering practices
Over 5,000 subscribers

Issue 435 - July 19, 2021 · Archives · Subscribe

Design Idea 💡

The software crisis

The software crisis was famously identified and named at the 1968 NATO Software Engineering Conference. The conference attendees noted that it was increasingly difficult to build software projects on time and within budget. As I read papers from the history of computing, this idea popped up again and again. And after 50 years, it does not appear to be solved. Frequently and recently, large software projects fail to deliver.

One explanation is the sheer complexity of the systems involved. As computing resources grew, so did our ambitions. It is akin to some of the over-budget physical infrastructure projects, such as the Sydney Opera House or the Montreal Olympic Stadium. Regardless of careful planning, unforeseen delays and other problems seem to plague the project's progress.

One of the surprising things I've heard from Christopher Alexander is that his projects are often completed faster and more cheaply than if you had built them more conventionally. The most important factor seems to be that he designs and plans the building in situ. That is, you go out to the place where you want your building, and you stake out corners, move them around, locate the doors and windows, etc. The lay of the land, angle of the sun, pre-existing structures, and tree locations all influence you while you're out there. The owners, architects, and builders are all out there working through the process. There is a lot of "sit here and imagine what the view will be out of a window here."

Conventional architects work on a drafting table (or computer) and dictate where things should be, usually trying to find an aesthetic solution that meets the owner's needs. The builder comes in later, mainly without the help of the architect. The builder tries to implement the vision in the plans as best they can. And when there are problems, the builder submits a change request back to the architect. They solve the problem and have to re-plan from there. A changed location for a door might involve redesigning the whole wall to redistribute the load. It costs time and money.

Of course, in software circles, we have names for these two approaches: Agile and Waterfall. As an industry, we know Waterfall doesn't work well. It is simply impossible to capture the complexity of a modern software project in specifications and get it right the first time. Instead, we proceed in small steps, do lots of experiments to test hypotheses, and work closely with stakeholders. Problems are identified earlier and worked around.

My question is: Is the Software Crisis an ill-formed concept? That is, do software projects go over budget because we think of them as projects? Today, we recognize that software is never finished. It doesn't go from "construction mode" to "maintenance mode." Software is constantly being built and modified throughout its life. The folly of the project mindset is the heart of the DevOps movement, which, more than Agile, is helping to reorganize the entire business toward delivering value through software.

Podcast episode🎙

This week on the podcast, I talk about the relationship between abstraction and generality.

Book update 📘

Thanks to everyone who has bought a copy. I love receiving photos of copies of my book in the hands of their owners. It is rewarding knowing that the copies are out there, having an influence on the world.

You can order the print book on Amazon. You can order the print and/or PDF versions on Manning.com (use TSSIMPLICITY for 50% off).

I can't recommend the Kindle version since I haven't seen it yet.

Pandemic update 😷

I know a lot of people are going through tougher times than I am. If you, for any reason, can't afford my courses, and you think the courses will help you, please hit reply and I will set you up. It's a small gesture I can make, but it might help.

I don't want to shame you or anybody that we should be using this time to work on our skills. The number one priority is your health and safety. I know I haven't been able to work very much, let alone learn some new skill. But if learning Clojure is important to you, and you can't afford it, just hit reply and I'll set you up. Keeping busy can keep us sane.

Stay healthy. Wash your hands. Wear a mask. Get vaccinated if you can. Take care of loved ones.

Clojure Challenge 🤔

Last issue's challenge

Issue 434

This week's challenge

Longest Delimited Substring

A delimited string is a string that starts with a character, ends with the same character, and doesn't contain the character anywhere else (besides the beginning and end). Here are some examples:

  • "abbbbbbba" is delimited because it starts and ends with \a.
  • "ajjjjaffa" is not delimited because, though it starts and ends with \a, it also contains \a inside.
  • "bkfifoifu" is not delimited because it doesn't end with the same character it starts with.
  • "aa" is delimited.
  • "aufodiufa" is delimited.

Your task is to write a function that returns the longest delimited substring of a given string.

Examples:

(delimited "ffdsfuiofl") ;=> "fuiof"
(delimited "abbcdefg") ;=> "bb"
(delimited "opoiifdopf") ;=> "poiifdop"

In the case of ties, return the substring that appears first.

Thanks to this site for the problem idea, where it is rated Expert in JavaScript. The problem has been modified.

Please submit your solutions as comments on this gist.

Rock on!
Eric Normand

Sean Allen
Sean Allen
Your friendly reminder that if you aren't reading Eric's newsletter, you are missing out…
👍 ❤️
Nicolas Hery
Nicolas Hery
Lots of great content in the latest newsletter! Really glad I subscribed. Thanks, Eric, for your work.
👍 ❤️
Mathieu Gagnon
Mathieu Gagnon
Eric's newsletter is so simply great. Love it!
👍 ❤️