Thursday, April 29, 2010

Software Quality

A few thoughts on software quality which seems to be a topic coming up more frequently these days. The first I'm throwing out there is software quality can be a fairly complex topic so a simple blog post is not going to attempt to do it justice. The next thought is software quality means different things to different businesses or organizations. The expectations of the space shuttle crew of their software is different from the folks who need an internal web page to track office supplies. Although it may seem like the folks who need the web page are in fact launching a space shuttle, that is not the case and the same rigor cannot and should not be applied.

Two areas in particular that I'm ranting a bit about are SOA and Agile(as in the development methodology). I read this post over at CIO.com on the issues that SOA and Agile bring out when it comes to software quality. I'm going to answer the question it's posing up front - no SOA and Agile do not lead to crappy business agility. I think most would agree that have had successful practices established around SOA or used the Agile development methodology correctly that the end result are more agile applications.

Organizations that skimmed the service of SOA or Agile could have implemented complete disasters for software. Does that make SOA or Agile the culprit? I think not and in fact I think those same organizations would struggle within any architecture or methodology. SOA and Agile don't shed the traditional principals of good software development practices, they simply enhance them to insure business needs are met in a timely manner. Like any architecture or development methodology if implemented incorrectly SOA or Agile can lead to bad results. If you have any thoughts on why SOA or Agile in particular lead to poor quality software, I'm all ears.

4 comments:

VP said...

I am currently working on one such large engagement. The successful model must emphasize the need for some amount of upfront analysis that would result in quality services. Often times, time pressures to deliver can result in unusable and not reusable services. Agreed that this is mitigated by proper sprint planning and other good program management practices. However reality tells that thy is not often the case.

Steve R said...

No SOA, WOA, Agile, RUP, you name the arch style or dev methodology are not the reasons for poor business system agility and poor software quality.

The reasons are myriad and stem mainly from the fact that we do not do a good job of, as @VP said, to spend a little time upfront to do the "complex-thinking" about the business operating model, what is the logical way to modularize our business capabilities and organize our applications and their interactions. And where in the application do we need to enable flex points because these items are more volatile from a change perspective than others.

So by trading off this upfront "complex thinking" we bolt things here and there and stand up this new module here and there and hook it across unexpectedly to another module and before you know it things start to break in unusual places and then we need to support this new business capability requirement which is partly supported here, partly over there.

I know I am preaching to the choir, but how an organization applies architecture, SDLC and project management is the ultimate drive, in my experience, of good or poor software quality.

Mark Griffin said...

Good comments, I think we are seeing similar things. The application of architecture and development methodologies is usually the culprit versus the actual architecture or methodology.

priscillatimon said...

I'm … very happy with your editing. Your writing reduced the length and
also improved clarity of the sentences. Most importantly, you kept the major...
SAP Training in chennai