Software Design Challenges

In recent weeks I have been faced with some serious challenges as I try to understand an application that was architected by my predecessor and his staff.

What I am quickly learning though is that without one key ingredient, transitioning control of an application will never happen successfully — that ingredient is communication.

Communication — the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs.

Dictionary.com

But that is not the intent of this post…

What I really wanted to touch on were some of the things that you should watch out for in any application that are clear signs of bad design. I do have to admit though, these don’t come from my head. They all do categorize the things I have seen but the categories were pulled from this book I own: Microsoft .NET: Architecting Applications for the Enterprise by Dino Esposito and Andrea Saltarello. I will however para phrase my understanding of each:

Rigid, Therefore Fragile

The way I understand this, is if it takes you twice as long to make a change to the module than it did to develop the module you have some serious problems. Scalability and flexibility must be accounted for in the initial designs. I have never been on a project where the requirements didn’t change and / or where the client was satisfied with the first release. The other thing to understand though is it’s not restrictive to one module, if you’re making a change to one and it cascades through out the application breaking things that should not have any dependencies with your change then you have a problem.

Easier to Use Than to Reuse

Pretend you develop a really nifty function that facilities printing from the web. I presume this to be a pretty common function in most applications, as such should be designed and developed to allow for it’s reuse. Now say you take that same printing function plug it into another application but you can’t get it to work. You have a problem, it’s most likely do to dependencies with other application modules. If you identify something that you know you are going to need elsewhere, take the extra time to design and develop it as such. The extra time will be well worth the investment.

Spaghetti Code to Lasagna Code

I really like the books explanation of this principle, it made perfect sense when I read it and looked at the pictures. The point here is straight forward, in the age of object-orientated programming your application should not be a maze of  “jumps and returns.”  Instead introduce layers and reusable pieces that allow you to logically segment the application and logic.

Cohesion & Coupling

The book separates these two, but I’ll talk to them together.

Cohesion, put simply, talks to a tightly packaged module. Something that has very clear and concise responsibilities and looking at it that responsibility is made apparent. In application development you are looking for high cohesion.

Coupling on the other hand is the opposite, in terms of what you want. This actually talks to the interdependencies between modules. Can this module exist without this module? Think the print feature above. When you have high coupling you run into problems like what I described with the printing feature, you are unable to move and reuse it because of some underlying dependency with another module in the original application.

In any event, these are the main categories that caught my eye and thought most of you could relate with. The book does go into a series of other factors to consider but these were, in my opinion, the easiest things to identify when taking ownership of an unknown application and things that should send off red flags.