Featured Post

A Brief Introduction to Software Stability in the Enterprise

Software stability is an interesting term.  As a software design paradigm, the concept was first proposed by my good friend, Dr. Mohammed Fa...

Tuesday, March 8, 2016

Agile Software Engineering in the Proper Context

Corporations the world over have misunderstood the value and the proper application of Agile Software Engineering.  Some companies have latched onto the "fun" factor and the empowerment of the developers as leading to a workplace with higher morale.  This is a good outcome to be certain, but it is but the tip of the iceberg.  You simply cannot infuse fun into the workplace with agile and expect to solve the problems of a 10, 15 or even 30 year legacy code-base and less so would you be wise to expect agile practices based solely on the "fun' factor and the empowerment of the developers alone to achieve high quality software.

Enterprise alignment with agile practices and business model alignment is needed at a bare minimum. If the business model of the organization is incongruous with the software engineering realities imposed by the underlying business model, then it is difficult to achieve a high level of software quality.

For example a high level of commercial flexibility is often perceived as a market advantage, but what is the point of delivering a scalable, public cloud based solution for your customers, if the business model requires the same engineering team to support a branch of the total code-base for each customer who has purchased the cloud solution the company offers commercially, The likelihood is that such competing demands will  result in even more defects in the codebase and a rather difficult juggling act to keep each of the customers happy.  A better solution is to design core Business APIs following the practices employed by Amazon.com.  When employing this strategy, there is an emphasis on building a stable core with a focus on a highly extensible architecture.  It is precisely this approach that allowed Amazon.com to deliver the substantially high level of customization of their web marketplace which allows them to quickly stand up highly customized store-fronts for many customners without having to write substaantial amounts of custom code for each client.

Over and over again, we in software engineering are told that the linchpin to high quality software is software that is developed in an iterative manner and most importantly that it is designed for testability and is inherently testable.  We are also advised that the processes for supporting the solution must be inherently and highly repeatable.  Lastly, we know to insist that the software is tested, comprehensively and repeatedly.  Some of the most respected software engineers that I have had the pleasure to know have adopted an additional principle which they strive to incorporate into their solution architectures, designs and coding; namely; "software solutions should be as simple as possible and no simpler."  I have adapted this principle and simplified the concept further, my mantra for software solutions is: "To produce high-quality sustainable software solutions, they must always be designed and constructed as simply as possible"  I do not invoke the caveat of "no simpler".  In my opinion, sustainable software is designed and developed as simply and elegantly aas possible and sustainability can only be achieved through simplifying relentlessly.

Frequently, developers in their excitement to chase the next new thing, thereby increasing the tools in their tool-box -- be it a new library, a new language, a new engineering technique or even a new design pattern -- will adopt the most convoluted and complex stack and tooling with negligible benefit over doing it in a more conventional manner.  For the software engineer in question, this provides some measure of accomplishment, perhaps some job security and allows that individual to flex his or her muscle to show how talented they are.  Such displays of bravado have no place in a software engineering team unless there is simply no better way of achieving the solution, but we in the profession must have the integrity to say "No." to needlessly complex solutions.

The most likely result of employing needless complexity in our technology solutions is that the software will be difficult to support and sustain. While there are many ways to achieve the simplicity, repeatability and sustainability of which I speak is by employing the concepts of Software Stability which I have blogged about in other posts.



No comments:

Post a Comment