Software Principle #2: Always Understand Your Context

There are two keys to successful execution: knowing what to do and understanding the environment or context. If you have those two things, you are sure to have success.

However, as everyone is aware it is insanely difficult. If what you are trying to do is incredibly difficult, then there is an excellent chance you don’t know what to do. Conversely, if you are working in a chaotic environment, it is hard to understand your situation.

That said, if I could pick one of those two, I’d always pick knowing my context. Context will help illuminate the problem and will let you know how to get the resources needed to discover what to do.

Business is always contextual. Whether you are in the business of open source and seeking adoption of your library or in the business of acquiring revenue and therefore customers, you must still find a full understanding of the context.

Know the context you are working in will ease many of the decisions you’re forced to make in the development of a system. Determining context can be demanding many times over because systems can live through different settings at different sizes.

Let’s use business to business (b2b) startups as an example: at first, the goal of the startup might be to add users by way of venture capital or other funding sources.

The context might then change to keep those users or building features to cross the chasm to enterprise clients. Once at the enterprise level, as it pertains to feature set, the context may even switch again to maintaining enterprise clients which requires a higher uptime, more supportability, and less active feature development.

The Path Well Traveled

As you ponder on how architecture can support all of these contexts, you’re in the same place as countless developers that came before you.

Many startup founders expect to rewrite their platform at least once, if not twice before reaching an enterprise level product.

I don’t believe this is a requirement as long as the startup, and the developers can understand their domain, know what application modules and parts will be replaced and a rough estimate at when, and keep those from being the core of the application.

It is not possible unless you understand your greater business domain and know how that domain may shift around you within your given market. So how does one learn context?

As this pertains to software, there are many things to understand as you execute. The sum of these parts is the context you are operating.

Quality

Since quality is often the most misunderstood by people, let’s talk about that first.

Quality is always contextual. Quality is also metaphysical: it exists between the beholder and the object or thought that would receive the title of “quality.” Quality to one person is not quality to another person. In software, we should ensure that we are tuning our quality levels to an appropriate level, lest we create waste or fail to deliver.

For example, too many tests can be worse than not enough tests as they can create too much rigidity within the architecture and prevent change. Too much documentation can lead to the same result, where more time is spent updating the documentation rather than the code itself.

The next most misunderstood principle is understanding the people within your context. Understanding the people who can impact your software development or system via their influence is not in itself political. Using this information to create the result that you want by providing information to select individuals and not others is political.

There is always a fine line between being political and ensuring]the job that needs to be done gets done. In general, communicating your actions and intent in a clear, open, candid way to the people in your context is the right way to go. It allows them to provide feedback to your actions while also allowing others to be included. Allowing people to feel less political and will no doubt garner more support as you will build a rapport with everyone involved.

To this end as well, knowing who makes decisions and ensuring you know which decisions they can and can’t make is essential for the success of the system you are delivering. Getting a quick decision within a context can mean software can be delivered quicker and start adding value even faster.

Software Ecosystem

The last misunderstood aspect to cover is the software aspect: processes and systems that interact with ours. While we won’t talk about managing our impact on our surroundings until later, we can talk about understanding the systems around ours. By doing that, you will understand what changes are possible and when it’s appropriate to make those changes.

Also, by understanding the process, you will realize the bottlenecks that will hold up your deliverables, as well as understanding how to move your code through the entire process so it can add value to our customers.

Processes here range from extreme lean methods to years upon years of waterfall to ship a single product. Compounded with understanding the people who help make that process work will allow you to be a better teammate and deliver value through the process faster than others in your organization.

Understanding your particular context is vital in being thoughtful. If you are unaware of the context you are operating in, then there is no way to manage efficiently or effectively. Also, it’s a good chance that you will not be able to finish the job to be done and your system or module will go unshipped which adds value to no one.

Understanding your particular context can take a long time, and just like in software, you should earn your complexity. That is to say: context is broad, but odds are there is a subset of context that once understood will elevate your execution to another level.

Regards,

Andrew Wolfe, CEO @Skiplist

Originally posted on https://www.skiplist.com/