Sometimes software development can be counterintuitive.
Building software is hard and massively fascinating.
You put together teams of people with different skills, different backgrounds, different education, different opinions, and different motivations. Then you ask them to create something that did not previously exist that solves an abstract problem that typically probably isn't well understood.
If building a house is the twelve-bar blues, building a software product is improvisational jazz. It takes technical skill, collaboration, creativity, and flexibility. And, like jazz, doing it well means playing notes that don't seem like they should go together--doing some things that seem unnatural or incorrect.
Li Hongyi, Deputy Director of GovTech Singapore, recently published a brilliant article simply (and beautifully) titled How to Build Good Software. I'd like to share some of my favorites of the points he made with my commentary about how they suggest that effective software development means doing things that may initially seem counterintuitive.
Failures of Leadership
The most impactful reason a software project will fail is not the lack of skillset or motivation from the engineering team. It's not the technical decisions that team makes. It's not the clarity of requirements or documentation. It's not the user's fickle nature.
When a software project goes off the rails, Li correctly calls out a failure of leadership, specifically a failure to define how to approach solving the problem that needs solved:
The root cause of bad software has less to do with specific engineering choices, and more to do with how development projects are managed.
The outcome of a given software project is highly determined by the principles under which the project is executed. Leaders of the software project (or group, or company) are obligated to establish and manage to the principles they believe are right for solving the technical problem at hand.
These principles will vary from organization to organization, but there are general ones that are more or less universal. Li suggests three...
- Start as simple as possible.
- Seek out problems and iterate.
- Hire the best engineers you can.
I agree with all three, and I insist you go further! As a CEO or CTO or Product Manager--whomever is leading a product or engineering team--develop the list of principles by which your team should operate. Then be crystal clear when communicating them and steadfast about holding to them.
Managing to principles is how you develop an engineering and product development culture, ideally the one best suited to solve the problems you need to solve. (I highly recommend the book Principles by Ray Dalio.)
Borrow Before You Build
Li describes the opportunity that today's ecosystem of open-source software projects presents for engineering teams:
[Open-source software] is the reason digital technology has made such rapid progress. Even the newest engineers can build upon the most advanced tools our profession has to offer.
Many engineer's first inclination is to write code to solve the "microproblems" that make up the ultimate problem. Yet, the richness and diversity of today's open-source ecosystem mean almost any "microproblem" that exists can be done so at least in part with code that a community of people wrote and maintain.
These open-source projects can be very micro, like a library for validating the structure of a JSON object. They can be broad and foundational, like a framework on which to build your entire user interface. They can be solutions unto themselves, like a content management system on which your solution is built.
Building effective software is continually less about being good at writing code and more about being good at assembling existing projects in creative ways that solve the ultimate problem at hand. It's about combining existing software solutions in ways that make 1 + 1 = 3.
The best coders aren't necessarily the best at coding at all. They are the best at engineering a system using software written by other engineers, filling in the gaps with their own unique code.
You Aren't Just Building Software
Li calls out the point that your engineering team isn't just producing code; they are producing an understanding of the problem to be solved.
Software should be treated not as a static product, but as a living manifestation of the development team’s collective understanding.
I agree, and I'd take it a step further. Software organizations don't exist simply for the purpose of building software. They serve a broader purpose, often a commercial one.
The code a team produces is merely a means to an end. The software solution is one (often important) facet of a system that includes developed software, commercially available software, people, vendors, physical space, AIs, etc.
Software organizations are complex organisms that seek to solve problems for other stakeholders, typically in exchange for monetary value. Ultimately that means you aren't building software. You are building an organization that produces value that can be exchanged for other kinds of value.
This is important to remember, because when making software design decisions you have to consider the systemic, human elements. How will it be implemented or configured? How will it be supported? How will it be distributed? How will marketers describe it? How will users describe it? How will governments or competitors or vendors interact with it?
It's easy to get to "engineery" and only worry about what you are building. While your teams engineering talent and the software it produces is typically of massive importance, the value your entire organization provides is ultimately the product. Keep focus on the big picture.
---
I highly recommend you read Li's article How to Build Good Software, because he makes a whole bunch of other points that are far more eloquent than my commentary.