The Pragmatic Approach
Today I wanted to talk about what has recently inspired me to re-evaluate the way I see myself as a developer and how it has changed my process for approaching problems in my domain. It starts with a simple word:
Pragmatic
Dealing with things sensibly and realistically in a way that is based on practical, rather than theoretical considerations.
A simple concept that guides us to look at solving the problems we face, instead of focusing on the solutions.
The Pragmatic Programmer
The Pragmatic Approach is a concept that you can apply to the programming field, which will enable you to become a more effective programmer. It allows you to make designs and decisions that are fit the problem better and are more time efficient.
As developers we build a lot of things…every…single…day. We build websites, tools, services, jobs, apps. When we first learn how to code, we follow the principle “Just Make it Work”, which gets us the solution, but isn’t the proudest thing we’ve ever worked on. As we gain more experience, we start to see different solutions and realize there’s better and better ways to do things. We start incorporating design principles such as S.O.L.I.D and using strategy patterns, and abstract factory patterns, and the next thing you know that 50 lines of code you wrote when you just started with has become 500 lines.
This design will probably produce the most beautiful code known to man (and woman), and it will be the most extensible, most readable, most efficient code to ever touch your code editor — that is if you had all the time in the world to write it. In reality we are constrained to design code between business deadlines, government regulations, and even sometimes performance metrics.
Are you saying we should build the quickest solution?
That is not to say that you should revert back to your initial design of 50 lines, because we have the experience to say that design probably won’t last a couple feature changes. Following the pragmatic approach, we need to discover what is a sensible or practical solution to our problem. A more relatable way of saying this between developers is to build with a “good enough” mentality.
“Good Enough” Mentality
The “good enough” mentality changes the way that we view software development, in that what we are focusing on building a solution that is “good enough”, rather than what is best. Through your experiences you will be able to determine what is needed now, and what can be integrated later when the time comes. You can design your systems such that it solves your current tasks, but also in a way that you are open to the possibility of change. Your system has the ability to adapt to changes in the future, without fully committing to these designs until they are needed.
A common understanding is that the more time you put into a task, the higher the quality the result will be. (Side note — I thought this graph was also relatable in that the more time we spend on our designs, the more confusing it can make the final solution.) The early parts of the curve would indicate a “quick and dirty” solution, whereas the latter part indicates the “best” solution possible. In the middle where it starts to level is the sweet spot that is “good enough” — where your return on investment (time) no longer benefits you as much.
How Much is “Good Enough”
There is no universal process for finding out what is “good enough” for every case. Different industries have different standards. Different projects have different timelines. Different people have different philosophies in maintainability.
How do I determine what is good enough?
That is a question you have find out for yourself — by using past experiences, talking with other developers, and communicating with management.
Here are some properties of a “good enough” solution to get you started:
- Good enough that it works
- Good enough that it can fit within the deadline
- Good enough that it can change with different requirements
- Good enough that it can handle some degree of unexpectedness — some uncommon use cases, heavy performance loads, or system failure for some examples
The Benefits of the Pragmatic Approach
Following this mentality can have a profound effect on your developer experience:
- You will be more confident in your assessments and designs
- You will be encouraged to evaluate all of your options, and trim down the answer to just the right size
- You will be more consistent in making delivery dates because you are taking time into consideration
- You will have better work/life balance because you won’t have to overwork to make up the difference between the best design and the one that will ship on the metaphorical next Friday
Trust the Process
The Pragmatic Approach is a concept that you will continually redefine throughout your career. You will gain more knowledge, learn more domains, and experience new problems — and with that you will be constantly honing where the position on that time vs quantity graph your solution resides.
The Pragmatic Approach redefines how you look at software development, and by applying the principles you will be able to create the most practical solutions.
I have seen the personal benefits of applying it to my work, and I hope that you can give it a try to.
For an in-depth look at applying pragmatic principles, check out the book “The Pragmatic Programmer”, by Andy Hunt and Dave Thomas
