Skip to Content

Fast and flexible

Clemens Reijnen
July 09, 2013

+31651113732 Blog: www.clemensreijnen.nlModern businesses need fast and flexible IT. Fast in the realization of systems to stay ahead of the competition. And flexible in the direction the system implementation goes to easily adopt innovations which can bring business benefit. Software dependencies A good practice for software development to stay fast and flexible is to take as less as possible dependencies. The well-known SOLID principles are a good example of this low-dependency practice to stay flexible. As can be read on the ‘The OLD Object Mentor blog site’: DSM dependency Poor dependency management leads to code that is hard to change, fragile, and non-reusable. On the other hand, when dependencies are well managed, the code remains flexible, robust, and reusable. So dependency management, and therefore these principles, are at the foundation of the -ilities that software developers desire. Image from: Evolution Analysis of Large-Scale Software Systems Using Design Structure Matrices & Design Rule Theory [PDF] referenced from Methodology dependencies Methodology dependencies This not only counts for code, but also for methodologies. When your team has many dependencies on other teams or managers, your team can’t be flexible and can’t be fast in the realization of a software system. Interesting is the diagram below, it is a visualization of the degree of coupling between different process elements in the RUP methodology.   Taken from an university study  The figure shows, that there is a very high coupling for approximately one third of all process components. 21 process components have a coupling less than 25%, 8 process components have a coupling of more than 25% and 3 process components more than 40%. It was shown that the RUP is customizable, but with significant limitations. The most significant limitation described is that the removal of roles and artifacts is nearly impossible due to the many dependencies among process elements. Current practices are all focusing towards this fast development. Agile (what’s in the name) and its methodology frameworks like Scrum are already widely adopted and practiced by teams. And, while the team internally is tightly coupled the dependency with the outer team world is very low, making agile teams flexible. The adoption of DevOps and the goal to be capable to continuously deploy software to customers is a major step companies take to be fast. A single dependency can ruin your day Lately, we had an outage of our and the blogs, an outage of four days! Which is gigantic in cloud terms. The cause was an external WordPress plugin that blocked everything. VINTblog It should be easy to solve (at least within four hours instead of four days), but due to two dependencies it took us several days: the the first were was the software dependencies, this blog is a WordPress blog engine with a ClearDB (MySQL) database, several open source plugins and hosted on Windows Azure. Where to start your investigation when things don’t respond anymore? Also interesting is the process of support calls you can have with the different vendors. Support on a system with multiple vendors can easily result in a deadlock (everyone helped us great, but without result and long wait times on each other due to different time zones / dependencies). The management wasn’t happy; the move to the Cloud promised them an easy fast and flexible system. Moving everything to a different blog engine, hosting or database wasn’t easy due to the many dependencies between them, maybe an export and import could have worked. The second dependency was the single person who had created theise blogs went on vacation. It is hard to solve a problem without having anyone in near distance with system knowledge, to tell what has been done on the system. Both the software dependencies and the process dependency made it hard to solve the problem. A solution for the process would for sure be software configuration management, having every bit in a source repository with history would have helped a lot to track the history of the system. This is a common practice in agile methodologies. From a software dependency perspective it is interesting that there wasn’t an exit strategy. Exit from the blog engine provider, database or platform, none of them could easily be replaced due to … again dependencies. A software development department that wants to be able to always say YES WE’RE READY FOR CHANGE to the business should definitely manage its dependencies, together with the business it supports.

About the author

Global CTO Cloud and DevOps leader | Netherlands
Creative thinker, solution and service builder. 20+ years of success with complex innovative software systems. Innovate on DevOps and to move to the Cloud and build Cloud services.


    Leave a Reply

    Your email address will not be published. Required fields are marked *

    Slide to submit