The better way to think about software engineering execution is to zoom out to a 10-mile-high view and discuss examples from physical engineering, as well as quickly visit our friends in marketing. First one will demonstrate limitations and gap bridging engineering has, and marketing gives us some insights on how to work with stakeholders.
Delivering smoothly, and in time are essential qualities of good execution. It is important to have a realistic understanding of where you are, and a clear view of where you need to be.
Understanding where you are is not only technological. It is about bridging market expectations. E. g. our understanding of transport is currently based on the fact we all used to carry all the fuel for the next phase of a trip with us. Whereas electric engines could allow for various scenarios due to more flexible availability of electricity.
Accumulation as we drive from solar panels. A practical real-life example which comes to mind is electric powered yachts. The design of their roofs was particularly accommodated for placing larger solar panels. These panels allow yachts to return to a harbor an hour after sunset with more than half the battery still full.
Pre-charging. Furthermore, liquid fuel created a habit of pouring needed energy into a car. This habit is so strong, that even other usual actions we make in different context do not help: replacing electric brush or toy car accumulators, and then charging used ones separately. Though, here price of car batteries and need to preserve lithium at least during this phase did move this “feature” out of original “MVP”.
The stations. The other side of the habit is the need for a specialized station where the fuel is stored. Electricity is universally available, and charging “outlet” doesn’t necessarily require storage capacity to be in a direct proximity. Hence, retail and coffee shops, malls, and other centers, and parking space overall are going to get boosts of their economical productivity due to these properties of the new tech.
Switching from examples of technology limitations per above to customer brings us to a marketing book “Why People (Don’t) Buy: The Go and Stop Signals” by professor A. Chakravarti (LSE), professor M. Thomas (Cornell). The book gives interesting insights discussing three manager types with misleading biases: the Vulcan manager which considers their customers are perfect calculators, the Hedgehogian manager which considers one approach fits no matter what context is, and the anti-research manager, which is right depending on novelty of their context, like a Schrodinger’s cat. Various business cases in the book show the importance of action-to-market fit.
Despite different areas these examples are quite relevant for software development. Like in EV example understanding limitations of current paradigms, and flexibilities new ones bring does matter. To give a more specific illustration: containerization makes automation tools like Ansible, or Chef obsolete in their own context, modern web development allows separation of concerns (API and frontends), and cloud computing provides capabilities for resilience.
Learning your customer’s habits when such habits exist is an important step of execution here as well: not every system requires to be run 24/7; every table, row and cell may have own specifics which determine how databases are built and scaled; each startup may have own set of virtual facilities which determine services you will take as SaaS, acquire and host as a grey box, or leave it to be fully homegrown.
The old saying goes*: flight of an idea is typically interrupted by a compiler output. In other words, if an engineer has a chance for mistake, they will make it; if they don’t – they will make it surely.
Hence, it is wise to assume nothing without experimenting. This will allow you to connect two points – now and then – with one smooth and confident vector. Vector which bridges a world of machines and the world of people.
* - I think it’s from old C++ book but may be wrong.
No comments:
Post a Comment