I could do that in a weekend (2016)

This is an excellent summary of the non-obvious realities of building software at scale. Engineers often become so good at building quick, weekend prototypes that they don’t understand the realities of shipping software at scale. Practically speaking, the initial greenfield software development is almost always a tiny fraction of the effort that goes into building a business.

This is a common downfall of engineers who try entrepreneurship before they’ve gained managerial or operational experience. I’ve lost count of how many entrepreneurs I’ve talked to who got something running on an Arduino or Raspberry Pi and think that they’re one step away from a successful business. Really, the hard work is only beginning.

I think this article raises a lot of good points about the weekend prototype, but I also think there is some merit in the question of “what do all those people do?”.

I’ve worked in digitalisation in the public sector of Denmark for quite some time. A few years ago I was part of the group who redefined our national principals for architecture in municipality IT systems. The whole thing is called rammearkitekturen which translates directly into “the framework architecture” and without getting into too much details it was made because we had 98 muniplacities times 300 average IT systems ways or defining what a person was. Which made buying and integrating IT hard. Rammeaekitekturen still hasn’t fixed that, but that’s not what I want to talk about.

One of the things to come out of this mindset was how to design an IT system for eldercare. Where there used to be a physical folder with a printed note containing all the “Moksly may attempt to hit you during showers and this requires two caretakers” and so on as well as hand written notes for day to day things, medicine used to come in little sorted bags clearly labelled “MORNING” and so on, and every morning people would get a printed list of their route that was adjusted for coworkers who were off sick and so on, and that was pretty much it. Today we have multiple different billion dollar systems to handle those basic things, and after two years of being used they still can’t handle differences between day and night-shifts or giving call-in temps the correct sorts of data access.

Instead of having two planners and a subscription to a pharmacy for the sorted medicine bags, we now employ almost 50 people as full time support staff to operate this system as well as throwing endless amounts of resources after project managers, lean consultants, educators and so on to get this system to work.

When polled everything single citizen and caretaking employee replied that the old non-digital systems were better. At no point has anyone asked whether or not it made sense to digitalise this area or if it makes sense to continue trying to implement it.

So I do think that it’s sometimes reasonable to wonder just what all those people are doing in some organisation. Because sometimes systems have a way of making themselves important to the organisation without actually being important to the organisation.

I've seen this so often. Almost every time something about Khan Academy's technology makes it to the front page here, someone brings up some form of this complaint. It got to the point at which I wrote a post [specifically to address why Khan Academy has so much code](https://www.kevindangoor.com/posts/why-khan-academy-has-so-m...). There's just so much complexity involved in making reliable services that provide features used by a variety of types of users.

One other thing he touched on in passing: people are assuming they'd know what to build from the start. Even in relatively trivial applications a lot of work goes into finding the right way to express what you're trying to build. I recently worked on a small app and spent 40 hours trying out different approaches to the user interface. The solution I went with could be coded up in about 2 hours, but I had to do 38 hours of work that eventually got thrown away before I arrived at it.

This sort of thing happens all the time in professional software development. Sometimes it is a waste of time, e.g. people rewriting things in a new language/framework for negligible benefits, but a lot of it is a necessary part of developing a polished app.

Any chance you could add, that wide text is really hard to read body > *:not(pre) { max-width: 600px; margin-left: auto; display: block; margin-right: auto; } pre { max-width: 1200px; margin: 40px auto; background: #f6f6f6; padding: 16px; }