Skip to content

SO Apps 6: Shortening Time-To-Market of Service Oriented Distributed Apps

December 27, 2015

Given the challenges of developing apps for modern distributed systems outlined in my previous blog SO Apps 4, Coping with the Rapid Rise of Distributed Systems, exactly what techniques can be used to decrease Time-To-Market (TTM) of these systems and apps? Below, I list specific techniques I have found that will speed your TTM, both in the development of the initial release and subsequent releases. Many of these are root causes of slow TTM.

Software Structure

  • Use Volatility based decomposition as a basis for designing your software architecture – The architectural decomposition of a system into microservices and their components needs to be driven by the goal of encapsulating the most volatile areas of the system into separate parts. This decouples high volatility areas from each other so they can vary independently. A volatile area refers to some aspect of the domain, system, or whatever that has a high probability of change at some point in the life of the system, and that such a change would be so great that it will cause severe disruptions to the system architecture if it were not designed to encapsulate these volatile areas. Code changes are typically caused by changing requirements or fixing bugs. Encapsulating volatile areas prevents such code changes from rippling through large swaths of the code base. When such code changes are well contained within a microservice and/or its components much, much less work needs to be done to make the change and a faster TTM results in both initial and follow on development phases.
  • Control the expansion of complexityTightly constrain the number of interconnections to prevent the non-linear acceleration of complexity from soon burying the project in excess code, slowing TTM more and more over time. See Figure 2 in my SO Apps 4, Coping with the Rapid Rise of Distributed Systems article for a diagram and explanation of this accelerating non-linear effect. Controlling this complexity is readily achieved by constraining interconnections as follows:
    • Limit and manage the number of interconnections between components within a service or microservice. A closed layered architecture works very well for this.
    • Limit and manage the number of interconnections between services or microservices themselves.
    • Avoid nano services (very, very tiny fine grained services) which will inevitably result in more interconnections, creating more non-linearly expanding complexity.
    • Avoid fine grained service contracts that require a lot of service operations since this inevitably creates more interconnections, and thus more non-linearly expanding complexity. Instead favor service contracts with fewer coarse grained service operations and “chunky” data contracts.
  • Focus your business logic in your services, not in your UI or split between the UI and services — With multiple UIs (web, mobile, etc) why set yourself up to have to make code changes in multiple places due to the business logic being sprinkled around?  Rather put all business logic in services as described above, leaving the UI to implement the presentation logic.  You’ll get a shorter TTM this way.
  • Strongly separate system concerns from business concerns – In all your code keep most of the developers focused on consistently adding the highest value by writing code that directly implements business logic, rather than having to write plumbing code that deals with system concerns while they are also writing business logic code. System concerns, implemented by plumbing code, are required for messaging, pushing data to clients, logging, auditing, etc. Push the plumbing code implementing system concerns down into utilities and infrastructure modules that the business logic developers can call. Having most of the developers spending significant time repeatedly writing plumbing code that can be done by a framework, base classes, or utility services will greatly slow your TTM. It is worth having this sort of system code developed very early in a project by a few highly skilled developers. That investment will quickly pay off in a faster TTM throughout the remainder of development.
  • Do the above 4 things at once and you have an Agile Codebase, one that supports increased Business Agility – An Agile Codebase will support future changes being done with a much lower TTM than is the current practice. Why? Because 4 of the root causes of poor TTM have largely been eliminated. The resulting Business Agility allows a business to adapt to changes of all sorts much more quickly, be the change an opportunity, a threat, or from rapidly changing technology.

Project Organization

  • Determine the Critical Path of the project (the sequence of development activities that adds up to the longest duration in the network of the dependencies of development activities) since it determines the soonest time a project will be done, i.e. the minimum TTM. Given the work that must be done and the sequence in which it needs to be done, without knowing the longest path how can one schedule work and even hope of achieving the shortest possible TTM? The Critical Path will affect your project whether or not you choose to use it to your advantage. This is key to creating realistic expectations in all project stakeholders, and hence credibility.
  • Put the very best developers on the Critical Path activitiesYour best developers have the highest probability of getting these TTM determining activities done sooner.
  • Test early and test oftenService oriented distributed systems require intense, repeated integration testing since bugs are much more difficult to detect and fix than in monolithic apps. Integration tests need to be written and run for each individual module, and also for each subsequent integration of tested modules into larger components or microservices. Do not delay integration testing to the latter part of the project when there is insufficient time to find and fix bugs. That is a sure way to increase TTM, and decrease quality.

Tools and Technologies

  • Favor pre-integrated sets of development tools and frameworksIt typically takes significant developer time to integrate a bunch of disparate tools and frameworks. And when a new release of them comes out with bug fixes it often takes additional developer time to integrate the new release into existing tools, frameworks, and code. All this acts to slow TTM. Much of this work can be avoided by choosing pre-integrated tools and frameworks.
  • Avoid using new “preview release” technologies just out of the box – While definitely interesting and alluring, preview release versions of new technologies and frameworks tend to be incomplete, have holes, have more bugs than usual, require many work arounds, have insufficient and sketchy documentation, require that developers spend significant time learning their basics and even more time to learn the best practices. Adopt brand new technologies in solid production releases, subsequent to the preview releases and speed up TTM as a result.

Classic Mistakes of Software Development

  • Avoiding making any of the “Classic Mistakes” will definitely result in a faster TTM – To be forewarned is to be forearmed. How many of the “Classic Mistakes” are going to happen on your next project? They will slow your TTM and they are avoidable! Below are some links I’ve found helpful in this area:
    • In 1996 Steve McConnell listed software development’s classis mistakes in his book Rapid Development. In 2008 his company, Construx, conducted a survey of 500 developers who rated the severity of the mistakes and then published a white paper listing the mistakes and summarizing the survey results. This white paper is definitely worth reading. You’ll have to register and login to be able to download a copy.
    • Peter Kretzman’s blog “CTO/CIO Perspectives: Intensely practical tips on information technology management” has a relevant article that looks at the role of senior management in this area: Software development’s classic mistakes and the role of the CTO/CIO
    • Jim Bird’s blog article Classic Mistakes in Software Development and Maintenance presents some of McConnell’s material, plus additional useful material from Capers Jones.

Near the end of this article please note that real world research from Capers Jones shows that “Not identifying and cleaning up error-prone code – the 20% of code that contains 80% of bugs” results in a 50% decrease in developer productivity. Here is an excellent way to decrease TTM.

I hope this list aids you in decreasing the TTM in developing your software as much as it has helped me.

George Stevens

Creative Commons License

dotnetsilverlightprism blog by George Stevens is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Based on a work at

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: