Let's devolve: Why going APE would improve software development

A proposal for Autonomous Programming Experts to develop end-to-end software

Tools are most effective when used to assist semiautonomous developers to design, create, test, and deploy horizontal, end-to-end component solutions. Instead, we're expecting them to use tools to attempt to corral a multitude of vertical resources working in various disciplines.

Share:

Randall C. Masciana (rmasciana@comcast.net), Consultant, Big Iron Software, Inc.

author photoRandy has consulted on process, tool use, software development, infrastructure, analysis, design, testing and deployment for corporate and government organizations of all sizes for more than 30 years. He has contributed several tutorials to developerWorks in the past.



09 August 2011

Also available in Chinese

Stretch a rubber band far enough and it can hold together many disparate items; stretch it too far and the rubber band breaks, hurting the entity that stretched it and allowing all of the potentially integrated items to scatter to the floor. We can use the development tools to make the rubber band stronger, but there are finite limits to what can be achieved with this approach. At some point, we have to limit the number of items that we expect the rubber band to integrate.

In the modern enterprise, development tools are expected to stretch along two dimensions:

  • On a horizontal vector, tools facilitate communication among related but quasi-autonomous programming initiatives of varying degrees of granularity.
  • On a vertical vector, within each of these horizontal initiatives, tools are used to elucidate interfaces among whatever architectural layers are required for end-to-end design of the initiative (requirements to deployment stages).

The need for the vertical vector evolved as a consequence of increasing specialization in the software development industry. Tools are now leveraged to assign properties and responsibilities to distinct work groups as an analog to the object-oriented approach commonly applied to software design, itself. However, just as in software design, this process can be stretched too far. A point of diminishing returns is reached, at which tools are required to help establish increasingly complex links among an increasing number of semi-isolated, vertically aligned human work units.

The development cycle typically begins when several layers of business and technical requirements teams create and distribute tool-generated artifacts across a horizontal trajectory. Interfaces are established among related but essentially autonomous development threads, and each thread can then be assigned to a vertical development team. Tools are effective on this horizontal vector of the software development process, just as they are effective in clearly communicating interfaces among the architectural components that comprise each horizontal, autonomous development thread.

How software development evolved to this dead end

But if tool use is stretched any further down the vertical dimension than assisting a single developer to create an end-to-end solution of an assigned component, parallels between the effectiveness of an object-oriented approach to software process design vs. an object-oriented approach to software technology design breaks down — cruelly and expensively.

In the current stage of evolution of the software development process, after a couple of generations, disparate human labor teams (web tier logic and configuration, middleware tier logic and configuration, database tier logic and configuration, messaging, networking, analytics, infrastructure design, configuration and deployment, and so on) become isolated colonies, separated at times by nearly untraversable expanses of what amounts to deep space, with wide gulfs in knowledge, culture, standards, vocabulary, priorities, and patterns. Communication and interfacing along this vertical vector, even if aided by the best of tools, is bound to fall far short of the optimum, resulting in costly iterations of failures, meetings, and rework.

But the cost is felt in emotional terms, too. Gone are the days when highly-paid programming professionals felt the satisfaction of taking even a single software component from requirements gathering through deployment, seeing that their effort resulted in solving an actual business problem.

Figure 1. Current paradigm, an evolutionary dead end
Code monkey drops components onto vertical layers

So, is software development now truly so complex that only the currently evolved model of interfacing among autonomous horizontal development threads, as well as attempting to interface among wildly diverse, vertical human work units, is the most efficacious process?

No. In fact, the opposite is true. The current branch of software development process design is an evolutionary dead end. We must now back-track it and choose a more survivable course.


Proposal for a more highly evolved, rewarding approach

To avoid the financial and human losses that are inherent in the current vertically afflicted model, we should now recognize the potential watershed that advanced software development tools have placed within our grasp. Modern requirements management, architecture, development, configuration, and testing tools, such as those offered in the various IBM® Rational® software tools, enable unprecedented advances through devolving the development process.

Tools can now be leveraged to enable what I call single Autonomous Programming Experts, or APEs, to create all of the vertical layers of any single autonomous, horizontal software component, from requirements to deployment. Endless gaps in interfacing multiple sub-components of an assigned component can now be closed by using the tools, not in an attempt to close communication gaps among vertical human groups, but, instead, to create the type of tightly integrated elements that can be achieved only in a timely and accurate manner by having the same APE create all of the elements. Endless meetings, redundant documentation, redundant human mediators, and resulting miscommunication can all be eliminated by an elite shrewdness of tool-wielding APEs.

APEs also use the tools to communicate well-defined interfaces with horizontal components created by other APEs. Tools have always been best applied to this horizontal dimension, and so optimal results are better ensured with this use of the tools than with using them along the vertical vector.

Figure 2. Highly evolved alternative process model
APE implements end-to-end across all layers

Of course, APEs cannot operate in a legacy, vertically oriented enterprise; they would need to function within an environment structured to support APEs. Initially, organizations would have to invest in cross-functional training and robust tool suites. But most existing code monkeys have already had to learn how to perform duties outside of their narrow, assigned discipline just to coerce various components of their code to finally work properly. In addition, most organizations have training and tools budgets, and these will be increased when the costs are seen to be far outweighed by the faster time to market and the more stable, easier to maintain, better documented applications that could be produced by APEs.

Analogous to APE software development, infrastructure requirements, architecture, configuration, deployment, and testing should also be performed by tool-wielding, human teams closely related to APEs. APE-oriented software/ infrastructure organizations would have to restructure their human resources to be, well, more human. Rather than deploying many lower-paid, factory-type workers who churn out-of-context, vertical products that are meaningless in isolation and that require an army of mediators to make those products fit with other sub-subcomponents, organizations would need to field fewer, well-trained, tool-wielding APEs, who derive great pride and job satisfaction from their efforts. Highly motivated APEs would then contribute to a company's success by creating optimized software that most efficiently meets real-world business needs.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=749689
ArticleTitle=Let's devolve: Why going APE would improve software development
publish-date=08092011