As a follow-up to my previous post, I had initially planned to go into more depth about my thoughts on Agile, but the result was much more an explanation of my personal approach to software development, so this post is going to be about that approach to establish a foundation from which I can build from.
Software development is about solving problems; I think this is quite well-established, but I do not believe our job is to solve problems exclusively through creating software, or even technology. But, how could we do otherwise? This is where I zoom out a bit and take a broader view on our roles as developers.
When approaching any problem, I like to start with the basics – the who, what, where, when, and why questions:
- Who are the customers we are building for?
- What, specifically are we creating?
- Where will the software be deployed?
- When is this (actually) needed by?
- Why are we building this?
These seem like, and certainly may be obvious questions for any established team and not ones that may need to be asked every time, so for the first four, I will simply point out to make sure you do know the answer to these and don’t simply guess or assume, because they are a critical factor in decisions, but are also easily answerable. What I would like to focus on is the why question.
Why are we building this?
Understanding the reason behind why we are building something is, to me, the single most important answer for building anything, software or otherwise. This is because the “why” checks the “what” by asking, “are we building the right thing that actually solves the customer’s problem,” but it also implicitly asks, “does the problem actually need to be solved” or “do we need to do this,” because the fastest way to get something done is to never have to do it at all.
Project delays and cost overruns are certainly detrimental to a project, but building the wrong thing could potentially be unrecoverable if resources are scarce. With a thorough understanding of not just what we’re building, but why, we can have much higher confidence our solution serves the needs of our customers.
My suggested approach is the Five Whys technique to understand the situation that led to the initial request. With this, it might be apparent that the solution may need to change, because there may be ways to solve the problem that are better and/or faster, but also may require us to get creative and step away from our computers to design real-world solutions. Let me illustrate this with a concrete example:
A manager is planning the company picnic and comes to you with a request to build a registration and tracking system for the event. They say it needs to have a place where everyone can register themselves and their families, edit that information if they change their mind, check-in at the event and have the ability to raffle off some prizes.
After some questions, you find out they expect about 30 people. Their main concern was that last year, they weren’t sure if all the people who signed up last time actually showed up and they don’t want to spend money for food no one will eat.
Though building it yourself is feasible, you instead create a Google Form to manage signups, find a clipboard and a notebook for sign-ins during the event, and order a small book of raffle tickets online. A one-month solution became a one-hour one.
The example may be contrived, but these types of everyday scenarios are quite common and with a bit of creativity we can find simple, effective solutions for what only appear to be software problems by not limiting ourselves to the lens of technology exclusively. Software is not created in a vacuum; we work inside a business which has many problems which are not always technological.
This concept of considering all the different factors into our development process is what I call Holistic Software Development, or HSD for short.
Holistic (adj) — characterized by comprehension of the parts of something as intimately interconnected and explicable only by reference to the whole.
It is the idea that not only does the software we build exist in a complex web with other applications, but that what we create and the environment in which we create them are inseparable and that this is something to not simply be aware of, but to actively try to understand and learn from, because doing so is not just good practice, but vital to our success. When we take these other factors into account, we can be sure that we’re solving the right problem in the right way.
Doing so requires us to step outside the realm of what we would typically consider the role of a developer to be, which is why a shift in mindset is necessary, because thinking in a software-only mode is our default. What we are rewarded with is many more tools in our problem solving tool belt, which increases our capabilities not just as developers, but as people.
This is the foundation of my approach to software development, but this post is not comprehensive and I intend to explore the concepts further in future posts. Until then, I hope this post provides a useful introduction and generates some interesting ideas for new ways to think about software. I do not plan to hold myself to a set schedule for when I publish new posts, but I do already have a queue of new posts I’m planning to write, so I’ll do my best to announce new posts as they get published.
Adam Lif 