Hello, I'm Steve Miller, Vice President for the SoftwarePlanner (ALMComplete, QAComplete, DevComplete) line of application lifecycle management products here at SmartBear.
If you’ve worked in software development and/or Quality Assurance (QA) for many years, you’ve probably found yourself in all kinds of thorny situations when it comes to the software life cycle. In 26 years, I sure have, and I have the bruises to prove it! Missed deadlines, buggy releases, upset customers and cranky bosses drilling me on why I didn’t foresee and proactively plan for these issues.
The honest answer is that software development and QA is very complex, has many variables, and is not an exact science – it takes planning and oversight to reduce the risk of things going wrong. Over the years, I’ve identified ways to mitigate many of the thorny issues that come up. The approach I use is to start with good engineering practices, measure what I can and make adjustments when I see things going astray.
Ever feel the need to jump in the car, put a blind-fold on and start driving break-neck speed? If you do, call me ahead of time so I can get the heck out of your way! Many of us take that approach in software development and QA -- we rush the designs, don’t track (or ignore) important metrics, and whine when we miss deadlines, ship buggy code, and have to face the customer when they identify the issues.
After banging my head against the wall for 26 years, my hope is that by sharing with you an accumulation of approaches I found as common sense
fixes for tough (yet common) issues that come up during the software development
lifecycle, I can help save your cranium. Now, if I could only figure out a way to keep my hair from falling out, I would be golden…
Let's start with helping you solve the:
"Why do I find myself rewriting the same code over and over again?" thorny issue.
So let’s say that you finish up the first iteration and things went well – you got into production in 2 months. But as you began working on your 2nd iteration, you found that you were writing very similar code as to what you had in the 1st iteration. Just because you are doing things in 2 month increments does not mean that you forget about applying solid engineering practices to the process –if you have not crossed this bridge yet, the 2nd iteration is where you want to really start applying good architectural discipline to your work.
If you are like me, you hate doing the same work over and over again. It’s all about re-use. Never code twice what you can code once. In my experience, the best way to re-use code is to separate the user interface, business, common utilities, and database logic into separate code modules. In most programming languages, this can easily be done with the use of object oriented class design. And you will also want to build a business layer than can be accessed through your application or can extend its use out to other programmers in the form of an API. This is called a Service Oriented Architecture and will save you tons of time in the future.
Confused about how to do it? Let’s take an example. Let’s say in our mythical Contact Management system that you took the time to write logic that would read a list of contacts (for the contact listing), added logic to validate the data entry on the screen when adding or editing a contact, and added logic to add or update the contact record to the database. If you placed all the logic in the user interface (logic for querying, validating data entry, and inserting or updating the contact record in the database), what happens when you get ready to build import routines later on (allowing you to import contacts into the database)? Well, you will be the writing code same code again (must query the database, must validate the imported data, must insert or update the contact record).
Now let’s imagine you had taken a more re-usable approach. Instead of putting that code in the user interface, you would have created a separate (business layer) class module for querying, validating, inserting and updating contact data. Then the user interface would simply call those methods and you will not have written the same code twice. This also reduces maintenance – imagine finding an error in your validation routines – make the change once in your business class module and you are done. Heck, you did so well, take the day off…
Now let’s really make our brains hurt. Let’s also imagine that you envision other companies wanting to write code against your Contact Management software that can query, validate, insert or update contact records because they have related data in their software product that could nicely integrate with what you have done. By simply turning that re-usable business layer into a web service (very easy to do), you can now expose those methods to other companies (in the form of a web services API) and not only can your team use the business layer, other companies can too. The coolness meter just went through the roof!
Separate your logic into 3 physical tiers (user interface, business layer – which would be a web service, and database layer), then you’ll be a rock star.
In the less than 15 minute video below I share with you some additional tips and tricks for solving the code reuse dilemma and at the end, an example of how a tool like ALMComplete can improve your chances at success. At SmartBear, we believe in providing individuals and teams with powerful, simple to use and easily accessible tools to help them solve an immediate problem. But even if you're not ready for a tool, you'll still find value in the advice I share.
Trouble seeing this video? Watch it here: Software Development Issues: Code Reuse
Stay tuned as I help you solve the next software development thorny issue, estimating and scope creep!
Interested in a free trial of ALMComplete?
Try out our related tools, DevComplete and QAComplete.