Often, people at work and outside have asked me this question (or a variation of it). I wished I could say that this objective is achievable at the turn of a key, just by re-architecting the solution, throwing more hardware or by re-writing parts of the code, But that would still provide a sub-optimal solution.
1“When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system. A good architecture is important, otherwise it becomes slower and more expensive to add new capabilities in the future.” ~ Martin Fowler
Ah, that’s the explanation I like. Software Architects are evangelists/crusaders who feel morally obligated to keep a system simple and flexible yet performant. However, can they alone deliver the optimal value? The 2bureaucratic burden can be overwhelming.
For the uninitiated, coding may be considered equivalent to erecting a structure brick by brick. Hours, days and months of hard work and commitment go behind it. There is no substitute to quality code. A compromise on quality today (often in the interest of time or money, or both) comes at a heavier price tomorrow – a popular cliché.
Often, developers find themselves at the crossroads where they need to choose between finishing a task ‘quickly’ vs. ‘doing-it-right’. The pressure to deliver often has had the best of us; we succumb to this pressure and choose a ‘quick-hack’ rather than a ‘permanent-fix’. Agreed, a temporary trade-off is fine, as long as there is a plan to put in a permanent fix later. If not, then almost without an exception, businesses have ended up shelling out more and more resources to keep this ‘hack’ plastered. Not a very wise business decision in the long-term, come to think of it!
Interestingly, solution design sits between and pans across both architecture and coding disciplines. In other words, a poorly designed code, a badly architected design, or a suboptimal design in itself could have devastating impact on outcomes.
3“When a process depends on a number of factors, its rate is limited by the pace of the slowest factor.” ~ Frederick Blackman
In short, there is no silver bullet. Equal emphasis on all the three aspects of a solution is needed. A carefully architected, well designed and coded solution shall any day outperform its competitors. One needs to, therefore, carefully and critically evaluate and refactor each of these. Since the ‘business’ side is often involved in making the calls when it comes to resource allocation, it is wise to have ample representation of, and communication between, both the money-allocators (business management) and service (software) architects to determine the optimal solution and the investments they warrant before they take on a project, to deliver a highly performant solution that will have positive ramifications on the company’s reputation in the long run.
Most businesses start with an idea. Various departments in the firm come forward to form a small team and collaborate to shape this idea into a working model or a POC. Department heads prepare a demo. Senior Leadership approves the working model post a critical evaluation of the product and its potential.
So far so good!
Now the real journey starts. This is when designated teams are structured and KRAs are defined. There is a race against time to make it to the market quickly. And in the larger scheme of things, what get’s compromised is “quality” – in architecture, in design and in coding too.
4Fig: (pseudo-graph) Effect of compromise in product quality.
This may provide a scope for faster delivery in the short term; but soon enough lower internal quality impedes the pace of delivery and experience. It is of prime importance to get “things that matter” or “things that are expensive to change later on” correct as early in the product lifecycle as possible.
Techniques like 5“concept sprints” hand-in-hand with a 6“disciplined agile delivery model” go a long way in optimizing the product and the delivery cycles. Analytics around product features, popularity amongst customers and an effective feedback loop are great contributing attributes to Product Backlog refinement and prioritization cycles.
Techniques like 7”YAGNI”enable Product and Engineering Teams to focus on the most popular and in-demand features.
