Top 10 post: “Fast and flexible”

Over the holidays, we will repost the top ten most popular blog posts of the year. This is one: Modern 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’: 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. http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Image from: Evolution Analysis of Large-Scale Software Systems Using Design Structure Matrices & Design Rule Theory [PDF] referenced from http://clemensreijnen.nl/post/2008/04/23/Rosario-Architecture-Explorers-Dependency-Matrix.aspx 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 http://www.micsymposium.org/mics_2006/papers/AltmannsbergerBuhlerRowe.pdf  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 vint.sogeti.com and the lags.sogeti.com blogs, an outage of four days! Which is gigantic in cloud terms. The cause was an external WordPress plugin that blocked everything. 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.