Shifting MOSA (Modular Open Systems Approach) to the left
The weapons systems world is changing. The technology is improving rapidly, requirements for performance are increasing and weapons systems are often required to have 30-50 year service lifetimes. The DoD believes an open systems approach can help. An open system approach considers how a system will be supported throughout its lifecycle at the beginning of …
Continue reading “Shifting MOSA (Modular Open Systems Approach) to the left”
Modularity as a Portfolio of Options
I have been exploring the use of financial analogies with regard to programming and design. Ward Cunningham’s Technical Debt metaphor has become well known. Prior to writing this blog entry, I looked a little deeper into Ward’s metaphor and discovered that it has been interpreted and extended in multiple ways. Since this is my view of the …
Modularity Parable and Software
In his seminal book, The Sciences of the Artificial, Herb Simon describes the parable of watchmakers named Hora and Tempus. They built watches out of 1000 parts. The watches were of the highest quality – as a result, they were often interrupted by customers calling up to place orders. However, they built watches using different techniques. Tempus …
Modularity and Agile Architecture
What is Agile Architecture? Architecture is an important aspect of agile software development efforts. It is critical to scaling agile to meet the needs of the business. “Agile architecture is a set of values and practices that support the active evolution of the design of a system, concurrent with the implementation of new business functionality”. The …
DevOps and Testing Software Architecture
Forbes Magazine famously wrote that “Every Company is a Software Company.” Your company must become more responsive and agile using software and technology. And if the software doesn’t work or gives customers a bad experience, it can lead to lost revenue. This has led to the DevOps phenomenon, which is speeding up deployment of software …
Reasons NOT to Refactor your code
Last week I wrote about the reasons to refactor code. Let us now look at some reasons why you shouldn’t refactor code. When dealing with legacy code there will always be a temptation to refactor the code to improve its understand-ability or performance. However, here are some reasons why it might be better to hold off: 1. …
Four Reasons to Refactor your Code
1. Maintenance is easier Legacy code architecture erodes over time and becomes difficult to maintain. Legacy code bugs are harder to find and fix. Testing any changes in legacy code takes longer. Even small changes can inadvertently break the application because over time the design has been extended to accommodate new features and the code …
Android Modularization
Out of the box, Android Studio provides one module: the app module. Because of this, most developers write their entire application in this one module. This is fine for small teams and small applications. But, as an application grows, more team members are added and the application becomes more complex, build times can increase – …
Motivation for Software Architecture Refactoring
Refactoring is commonly applied to code, but refactoring can also be applied to other development artifacts like databases, UML models, and software architecture. Refactoring software architecture is particularly relevant because during development the architecture is constantly changing (sometimes for the worse; see our blog post on Architectural Erosion) and expanding. Software architecture refactoring should happen regularly …
Continue reading “Motivation for Software Architecture Refactoring”
