From the outside, most software development projects look like a product of intelligent design. I think this is the fault of marketing, which describes software like this:
“Start using the globally scalable FooBar service today! We publish and consume any data using advanced machine learning algorithms to geo-locate your files and optimize them into cloud-native bundles of progressive web assembly!”.
In reality, developing software is more like the process of natural selection. Here’s a different description of the FooBar service from a member of the development team:
“Our VP has a sister-in-law who is a CIO at Amaze Bank. She gave our company a contract to re-write the bank’s clearinghouse business, which relied on 1 FTP server and 25 fax machines. Once we had the basic system in place the sales department started selling the software to other banks around the world. We had to localize into 15 different languages and add certificate validation overnight. Then the CTO told us to port all the code to Python because the future of our business will be containerized micro machine learning services in the cloud”.
This example might be a little silly, but software is more than business requirements and white board drawings. There are personalities, superstitions, random business events, and, tradeoffs made for survival.
In my efforts as a trainer and presenter I’ve been, at times, discouraged from covering the history of specific technical subjects. “No one wants to know what the language was like 5 years ago, they just want to do their job today”, would be the type of feedback I’d hear. I think this is an unfortunate attitude for both the teacher and the student. Yes, history can be tricky to cover. Too often the history lesson is an excuse to talk about oneself, or full of inside jokes. But, when done well, history can be part of a story that transforms a flat technical topic into a character with some depth.
As an example, take the April 2017 issue of MSDN Magazine with the article by Taylor Brown: “Containers – Bringing Docker To Windows Developers with Windows Server Containers”. Throughout the article, Brown wove in a behind the scenes view of the decisions and challenges faced by the team. By the end, I had a better appreciation of not only how Windows containers work, but why they work they way they do.
For most of the general population, making software is like making sausages. They don’t want to see how the sausage was made. But, for those of us who are the sausage makers, a little bit of insight intro the struggles of others can be both educational and inspirational.