In the product development world we spend a lot of time implementing and creating methodologies and frameworks. Some are followed dogmatically and have essentially become a religion, some are followed in theory but no one really understands them or enjoys working with them. Some require very expensive consultants or special roles to implement and some just require you to read a blog post on the internet. Most teams follow ‘Agile’ development practices, most companies utilise some form of feature prioritisation framework and some companies follow fancy management methodologies.
All of these frameworks are abstractions on top of the low level aspects, or levers, of an underlying system. Every framework/methodology we implement or concept we follow works, or does not work, for a reason. There is no magic in the framework itself, it is only beneficial to us because it packages up behaviours and concepts which act on the underlying truths/principles of a system and provide an easily understandable way to act on them. Scrum doesn’t work because it is Scrum, it works because it advocates for a package of easy to follow behaviours which increase the chances that we ship software effectively.
The behaviours, concepts and structures provided by a framework/methodology are abstractions on top of the ‘real’ keys to success for a system. This reality is usually hidden from us or involves a lot of work to fully understand, otherwise it would be obvious how to work effectively in a certain system and we wouldn’t need the countless frameworks or methodologies which are always being created. In some cases it is impossible to find the correct levers to pull to work at the low level of the true reality of a system and so we build the abstractions mentioned above. Even if these levers are identifiable it often involves diving deep into a subject. And so to make our lives easier we create frameworks, methodologies or concepts that remove the need for us to fully understand how the system works.
Things work similarly with programming languages. The average developer writes easily human readable code in a language which is built on top of lower level languages that a computer can understand. The developer doesn’t need to know how a computer actually works, where a variable is actually stored or how computer memory is cleaned up, to write working software. Modern programming languages are abstractions that sit on top of the ‘reality’ of a computer, the 1s and 0s it reads and the physical makeup of the CPU and RAM. You can think of modern programming languages as equivalent to the frameworks or methodologies mentioned above. Agile, DDD, and pair programming abstract away the true reality of what is happening in the same way that Javascript, Python and C++ do.
Over the next few months I will be going one by one through various software development methodologies and frameworks. I will be explaining the real reason they work, and don’t work, by going back to the first principles they act on. I will talk about the danger of not having this understanding and in some cases question the need for the framework at all.
I will be referring to this underlying reality and the levers we use to move it as the ‘first principles’ of a system. The term first principles is often understood to mean a principle which can’t be further explained by or deduced from anything else. It is what you find if you keep asking why something is the way it is and searching for the level of abstraction below. Eventually you can’t go any further. I will be using this concept somewhat loosely as for what we are talking about we could always go deeper. I will (mostly) be avoiding discussing the biology of cognition or machine code. My main aim is to get as far towards first principles for the areas I am focusing on to be helpful and no further. I will largely be concentrating on the first principles of everything involved in bringing software products to life.
While blindly following a methodology can lead to some success, it will just as likely lead you to failure if you don’t understand, at least superficially, why the behaviours it advocates are effective. As soon as things happen that aren’t mentioned in the book or blog post you won’t know what to do. As soon as one of your team asks for more information on why we are doing a certain new thing you won’t know what to tell them. A software developer can have some success learning the top level abstractions of a programming language but they will be much more successful if they have at least a vague understanding of how the code they write ends up moving the pixels on the screen. In the same way, having a real understanding of what a new behaviour mentioned in the methodology you are following is will help you become much more effective, skillfully work through any issues that come up and effectively sell the new ways of working to your team and management.
Currently planned are articles on Agile, domain driven design, servant leadership, microservices and much more.
Back to writing