Considering the influence of the seminal text, The Pragmatic Programmer, I often consider the intention of the lessons within and the culture, dare I say dogma of pragmatism in the software scene.
If we consider that Pragmatism, loosely defined, is an assertion that objective reality is best viewed in terms of their practical uses and successes(Wikipedia). Specifically, in relation to software development, we as developers are responsible for making features “work” in a pluralistic, problems-oriented environment. Let's explore the complications of this implied pluralism.
It might be easy to only view the natures of pragmatism in software as competitive, but development is a considerably flexible act where conflicts can be moderated by perspective change. Nonetheless, here is a non-exhaustive list for consideration.
Quality, Cost, Time Model
Product Accuracy / Solution Completeness
Risk
Entropy
Communication
Prototyping
Design Orthogonality
You might be catching on to the fundamental complexity that an individual IC(Individual Contributor) might encounter when walking the path of pragmatism can be biased. Regardless if this is due to opinion, wisdom, knowledge or directed by leadership and culture, pragmatism is too broad to observe.
So, here is where we encroach on dogma, and its toxic impact on software development. Pragmatism is a complex topic that is often “simply” explained. Like any sufficiently complex concept, practice and study, is our best defense against erroneous opinions. The risk we run is not having a holistic approach to identifying and repeating pragmatism.
So, I figure this was a good opportunity to share something I found while researching a larger body of work, https://github.com/HugoMatilla/The-Pragmatic-Programmer. Within is a lovely abridgment of the lessons from the book. Now let's compare and contrast the philosophy and the reality of pragmatism.
I think we often approach solving conflicts like the fundamental application of pragmatism by exploring case studies, but since ideologically it's a philosophy, we should try our hands at building a tool set to better understand how we consume it. So instead, we can try to better identify if we are following the practice or the ideal.
Some questions I ask myself:
Am I sufficiently confident that the problem is well-defined?
Am I chasing the problem as opposed to fixing it?
Do I need to take into account violations of the “Law of Demeter”(Prag)?
Have I reviewed the current solution before I started (Maintenance/Enhancement)?
Do I understand the contracts in play(Prag)?
Can I produce assertions for the change to be produced?
Does this make me want to introduce a refactor pass?
Now let's dig in a little further and try to extrapolate the pragmatic outcomes from these questions.
The first two address reactivity and competency to start working. It's a measure twice and write once mentality. Pragmatism as a dogma of small and simple often pushes for action as opposed to development of intention and a plan. Problems, frequently, are not isolated, they are part of a system that takes care to understand. Some context clues here, frequency of code change in the target domain and perceived complexity of the code.
If the code seems to have a lot of collaborators to complete single actions, alarms should be raised that you need to be prepared for more effort. Some context clues are; the combination of delegation, singleton, and inheritance within the same module. Numerous function which have the same or similar name with variable arity.
The rest are about training myself not to provide a commitment to delivery until I have reviewed the existing solution. Preferably I would like to approach problems using TDD (Test Driven Development) but let's be honest we are going to be lucky if we know enough about the solution to write blind tests for a sufficiently complex system. This is approaching a completely different topic but, tests contain assertions and if we use the provided text for guidance here, assertions are the secret sauce. The tricky part is that assertions in practice produce an exceptional state when violated. If we choose to handle these states or use guard patterns, we must assure that they are not introducing or hiding side effects.
Software developers have many roles, but the primary one will always be Change Management, and here is where I come to my last observation / concept, refactoring. Like all things “agile”, refactoring should be progressive changes to reduce risk or omitted entirely. The choice to refactor and when is the most powerful inherent benefit of pragmatic decision-making. All refactors should be considered non-trivial actions unless a suitably concrete case can be produced that would produce a positive constant multiplier of value. It's best to document ugly code, learn from its failures and leave it be, then seek the idealistic justice of a refactor. The simple litmus test is if you don't feel you could go to your manager and propose the refactors benefit to the business, you probably don't need it.
If there is something here you disagree with, then that's probably a good thing. Our source material, first published in 1999, like any influential text, has to be constantly measured for validity against our current lives and careers. If we do not, we risk allowing the ideal of pragmatism evolve into a dogma without the value of its fundamental meaning.
Top comments (0)