Software Architect Category: Software Architect - Page 5 of 51

On any project that is in production (i.e. it has customers that are using it), there will come a time when a change must be made; either a bug needs fixing, or a new feature must be added. At that point there are two possible choices; you can take the time needed to “do it right”, or you can take one or more “shortcuts” and try to get the change out the door sooner.

Generally,the business people (sales/marketing and customers) will want the change made as quickly as possible while the developers and testers will be more interested in taking the time to properly design,implement, and test the change before delivering it to the customers.

As the project’s architect you’ll have to decide which makes more sense and then convince the decision makers to take your advice; and as with most architectural issues there is a trade-off involved. If you believe the system is reasonably stable then it may make sense to go the “quick and dirty” route and get the change into production quickly. That’s fine, but you need to know that in doing so your project is incurring some “technical debt” which must be repaid later. Repayment, in this case, means going back and making the change in the way you would have if you’d had the time and resources to do it right the first time.

So why the concern over making changes properly now versus later? It’s because there’s a hidden cost to making these quick and dirty fixes. For financial debts the hidden cost is called “interest” and most anyone with a credit card knows how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked in changes, the lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid.

Now that you understand a bit more about the true cost of technical debt, you might decide the price is too high and you can’t afford the cost. But when it’s a choice between having the developers get the fix out as quickly as possible or taking a severe financial hit, it generally makes sense to get the fix out quickly. So take the hit and get the change into production ASAP, but don’t stop there.

Once the fix is in production, have the developers go back and fix it properly so that it can be included in the next scheduled release. This is the equivalent of charging something on your credit card and then paying off the balance at the end of the month so you don’t get charged interest. This way you can provide the fast changes the business needs, while keeping your project out of debtor’s prison.

'Coz sharing is caring

Software engineering is often compared to well-established disciplines such as civil engineering. There‘s a problem with these analogies; unlike the very tangible products created by these traditional practices, software doesn‘t really exist. Not in the traditional sense anyway. Those of us in the world of ones and zeroes aren’t constrained by the same physical rules that bind classic engineering paradigms. While applying engineering principles to the software design phase works well, assuming you can implement the design in the same manner used by more traditional engineering approaches is unrealistic.

Both business and software are living, moving entities. Business requirements change rapidly due to things like newly acquired business partners and marketing strategies. This makes it very difficult to approach a software project in the same manner as a traditional engineering pursuit such as bridge construction. It is highly unlikely that you’ll be asked to move the location of a bridge halfway through a construction project. However, it is very likely that the acquisition of a business partner will require you to add support for organization-based content management to an application. This comparison should put things into perspective. We often say that software architecture decisions are difficult to change but not nearly so much as things that are literally and figuratively set in stone.

Knowing the products we build are pliable and that the requirements surrounding them are likely to change puts us in a different position than someone building an immovable object. Engineering endeavors of the physical flavor are much easier to implement in a “plan the work, work the plan” nature. With software things need to be tackled in more of a “plan the work, massage the plan” fashion.

These differences aren‘t always bad news, at times they can be advantageous. For example, you’re not necessarily constrained to building the components of a software system in a specific order so you can tackle high-risk issues first. This is in direct contrast to something like bridge construction where there are many physical limitations surrounding the order in which tasks are accomplished.

However, the flexibility of software engineering does present some issues, many of which are self-imposed. As architects we are very aware of the “soft” nature of our craft and we like to solve problems. Worse yet, the business owners are vaguely aware of these facts. This makes it easy for them to push big changes. Don‘t be too eager to accommodate large architectural changes just because it appeals to your solution-providing nature. Decisions like that can break an otherwise healthy project.

Remember that a requirements document is not a blueprint and software doesn‘t really exist. The virtual objects that we create are easier to change than their physical world counterparts, which is a good thing because many times they‘re required to. It‘s ok to plan as though we‘re building an immovable object; we just can’t be surprised or unprepared when we‘re asked to move said object.

'Coz sharing is caring