What is Full Context Development and why do you need it?

And we are not simply talking about a team lead role, the goal is technical leadership, the higest level responsibility in tech decision making. What do you think, what is the most essential skill to fill such a position? Programming excellence? Soft skills? People skills? All of them? While I don't want to downplay their significance, if I can only choose one, I will choose: value-based decision making. This is something that needs a bit of explanation. It means having deep understanding about the context of technical decisions and the relationship between software engineering concerns and financial interests.

If you worked in the field of professional development for a while, I'm sure you already read a 1000 comparison articles (or watched videos) about the different technologies that aim to solve the same problems. Java vs C#, React vs Angular, MongoDB vs MySQL, AWS vs GCP, Terraform vs CloudFormation and the list goes on to infinity. I don't know about you, but I have often felt let down by these reviews. They usually talk about learning curve, productivity, level of support, community size, differences in approach and implementation, performance, and probably some picking on style and other personal preferences. It's all well and good for a while and let's be honest with yourself and each other, it will stay between software engineers. Aren't you making choices based on what you "like" the most? I sure do. What seems more interesting, what brings new and exciting ideas to the table, and probably where all the hype is, the tools evangelized by our favourite developer celebs.

We all get enthusiastic and pick what seems 'the best'. Then we get emotionally attached to our choice and try to defend it if its position as 'best' is contested. It's understandable. We invest major effort into learning these tools and bet our current and future employability on them. Nobody wants to admit they choose a mediocre or worse, poor technology that might go out of fashion and lose the potential of making big money. I think this is a major part of how our psychology works and this gets reflected in the comparisons. Even if they seem objective. Their whole perspective is about things we developers consider when making investment choices about our skills. The creators and advocates of the tools want to win us over, because in a sense we are the kingmakers. If you can capture the heart of software engineers, the technology will most likely become adapted and a financial success. That's why you see developer experience emphasized so much and emotional language used like 'awesome' and 'cool' in many comparisons.

Until I became a lead developer - maybe in part thanks to my inexperience - I really liked these articles. I lacked the self-reflection and wider perspective that shines a different light on these reviews. They often end with the seemingly wise conclusions. "There's no best tool. They have different pros and cons and you need to pick the right one for the job." When I finally had the responsibility to pick the right one for a job with major money on the line, I started to wonder. How can I explain to the stakeholders which one is the right one in our situation? None of these articles hint at the benefits those technical properties bring to the table from the business point of view. How am I supposed to tell if React or Vue will offer a better user experience for our target audience? Or how would they affect our release performance? How much faster will we resolve production issues if we use AWS DynamoDB vs our own hosted PostgreSQL database? And how much would that improve our overall customer satisfaction? Nothing that interested the people I had to sell my ideas to was outlined directly in these articles.

You might think that's fine. There should be other resources for IT leaders. Let me tell you, there aren't many - especially for free -. Or you might say, well, it's a leader's job to tell how those properties translate to the business world. Fair enough, but why aren't we helping the leaders with such resources? Well, I guess the answer is because regardless our position; we are still not really interested in the business. Business doesn't sell to developers. However, the sad reality is that the ultimate goal of *every* developer is to ship business value. That's why we have a job. Nobody reads our code like poetry. Our users - but from this perspective it's better to call them our customers - only see the software we create and only care about how it solves their problems. If you progress far enough in your career it's inevitable to face this reality and start making decisions with others in mind. Or if you work at a competent software company, caring about the impact of your work is a part of the promotion criteria list. I felt let down again and again, because there's no focus in most of our comparisons on customer experience or organizational efficiency and consequently business results. This is what (should) really matters when we decide what to use. I would love to read some top 10 programming languages articles that tell me what kind of projects would benefit from adopting a certain language and exactly how.

But heck, can you even tell me the basic ingredients for such a comparison? What kind of technical properties does for example React have over Angular or MongoDB over Cassandra that makes a difference in the business sense, and more importantly, exactly how much difference? To me, that would be the point of comparing different tools that aim at solving the same problems. The issue is, in general, that we don't really know the business relevance of technical properties nor how to connect them with financial outcomes. I see vdom diffing vs direct dom manipulation, terse vs bloated code, hooks vs classes, eventual vs strong consistency, smaller bundle sizes, incremental rebuilds, hot reloading. OK, but I need answers to questions like: How much does it help to reduce the price/cost of the software? How much will it help to hit a revenue target in the next quarter? How many more users will we be able to serve? Or how will it affect the site's conversion rate?

I decided enough is enough. It's time that someone gets to the bottom of this. It shouldn't be that hard to identify the relationship between the technical properties of programming technologies and the kinds of business effects they can create. I figured, we only need to get it done once, then we all can use the static connections as a map to find any relevant consequence of having or missing some technical attributes. This is one of the main goals of Full Context Development. However, it turned out to be 'that hard' and even harder. During my work on identifying these relationships, I found that it requires a transformation of our mindset to really get what this is all about. So the results became much more than a simple map.

Full Context Development is a set of principles about the role of software developers that the best of us have always lived by, but we never gave it a name and definition before. It's also a set of practices that translate the principles into everyday application. It has 3 "axioms" at its heart:

I will generalize here, so I acknowledge there are (many) exceptions, that might include you. That's fine. My goal is to paint the big picture, and I believe the following points apply in general. (If you disagree, let me know in the comments.) Most developers go to their first job with either computer science focused studies behind their back or with typical bootcamp/self-taught knowledge that's purely about how to build things. Of course, by that time, many of us have developed side projects or even full sized applications. What we didn't do is (obviously) fine-tuning software products to achieve better financial results. Nor did we try to improve large-scale organizational processes for better efficiency and effectiveness. (eg.: software development) We also didn't care a bit about how to do these. Full Context Development is an acknowledgement of the reality that nonetheless our ultimate task will be to write software that sells and to do it in a way that optimizes the operation of the company as much as possible all the while taking care of our own needs and fulfillment. I guess you haven't been taught how to do that right?

The practices of Full Context Development are all about making tech decisions because choosing the tools to use and the way to use them are the most impactful decisions software developers can make. Its goal is to show the connections between our actions and their effects on the customer's experience, the performance of the organization and through these the financial performance of the product. It's core belief is that by connecting developers to the final results of their work, they get more motivated, empowered and invested in creating great products, not simply great code.

Not by the developers, but by the people we work for. On the highest level, software is an exploration of ways to create value for the users and the businesses. In that sense nobody is paying for the code we write, they pay for the outcomes it produces. That's what matters for the 'business people' and they are desperately trying to discover the connections Full Context Development describes. The only issue is that they are not equipped with the technical knowledge necessary to find them. The results? At best, missed opportunities. At worst, failing projects and lost investments. None of them are good.

It fills the gap between tech and business. It might also fill the one between a senior and a lead position. It benefits everyone. The company gets software which sells better. The users get software that solves their problems more effectively. The developers get confidence in their decisions and recognition for the success of the product. At least that's the idea. Life is never that simple, but the Full Context Development system has the potential to deliver these, if used properly. It helps to get our real tasks done. (Once it's finished, as of December 2021 it's in early access.)

The backbone of this system is twofold: First is a way to identify every aspect of the: business model, user base, organization and project that should influence tech decisions. The second is a method to evaluate the impact of any technology related change over the 4 main areas that drive business value. Namely: Customer Experience, Productivity, Utilization and Business Opportunities. Their potential financial effects are defined in the system so you can use these to reach the outcomes of any tech choice. The only real task is to find the affected quality attributes of 3 things: code, software and processes. Their influence over the other elements of the Full Context are documented an can be traced back all the way to the final measures: R.I.P. CAR. Which is an acronym for: Revenue - Increase, Protect. Costs - Avoid, Reduce. The Full Context definition of business value.

For more in-depth introduction check out the landing page or the Intro chapter. The book overview describes the entire system, just as the other 2 free chapters. For the complete experience, you can already sign up.