Skip to main content
author avatar
By Tyler Tracey Software Engineer

*Views, thoughts, and opinions expressed in this post belong solely to the author, and not necessarily to SemanticBits.

Software Engineering is a curious little title. When I first began my career as a young programmer, I found the term “software engineer” amusing. To me, it seemed an overinflated mantle that programmers gave themselves to either buff up their resume or sound more important than they really were. Like with any profession or hobby, though, the immense complexities of the subject revealed themselves to me over time. As I matured in my career, I began to see software engineering as an art and that complex teamwork brings it all together.

I write this from a small coffee shop overlooking the St. Johns river. The sweet aroma of coffee and the beautiful sunset allow my thoughts to drift with the soft indie music playing overhead. Unfortunately, I’m not the only one drifting, as it appears that a bug is floating in my coffee. How sad that something so small can ruin something so sweet.

The art of software engineering is just like my large, iced, hazelnut dark roast—a delicious mixture of business requirements, customer clarity, and development practices within an Agile workflow that turns into the perfect blend of productivity and results in a great piece of software released on time and under budget. It all comes together if each team member does their part, and nobody becomes the bug simply drifting along in the Agile brew.

Agile Software Development Lifecycle

Let’s take a look at how we avoid that bug in the context of Agile software development. Agile development is more of a buzzword these days than a real manifesto. Agile, in its rawest form, describes a software engineering lifecycle, a way for software engineering teams to organize their workflow to get the most productivity out of their time. The specifics of “true” Agile are agnostic from the point of this article, only that it is meant to address the complexity of software development in a way that avoids those nasty bugs. So, to see how a bug can be avoided in the Agile brew, let’s look at development in action and see who’s involved.

The Customer

Zark Muckerberg owns a small bakery called Panoora. His clientele has gotten bigger and he has even started making home deliveries. Zark has decided he really needs a website with online ordering and GPS tracking for his delivery drivers. Zark contacts XYZ, a software development firm, and contracts his website to them. Development commences.

As the customer, Zark is the person or entity for whom the software is being created, in this case an external business or individual. Sometimes the customer is the company you work for and the software is just for internal use.  While the customer has the least involvement in the actual development of the software, they have the most impactful role in the quality of the final product.

It is the customer’s responsibility to fully understand the problem that the software will solve and to clearly and concisely relay the requirements of the software to the development team.  Effective Agile development will involve a business team who will coax those software requirements out of the customer. Yet, a good customer will know and convey what it is they want.

To put it in terms that Zark Muckerberg might understand, imagine someone ordering a bagel. They choose a plain bagel with cream cheese and the cream cheese gets spread onto the bagel. But then they decide they don’t want a bagel; they want a scone. So the bagel is thrown away, only for the customer to realize they actually did want a bagel. The person preparing the product for the customer is running in circles trying to accommodate them. In software development, the customer can be the cause of most major hiccups, the real bug in the Agile lifecycle.

A prepared, knowledgeable, engaged, and decisive customer will help lay strong foundations for the software to be built upon. If Zark really wants his bakery website to be solid, he should approach the XYZ development team with a well-defined list of the features he wants. He should also make himself regularly (read, not constantly) available to the development team for feedback and questions. Being flexible and open to advice will be also be helpful  when the development team proposes things that may not have crossed the customer’s mind.

The Business Team

The business team is a unit within the development team. In this case the business team would be a group of individuals from XYZ, the company Mr. Muckerberg has chosen to develop his software. The business team’s responsibility is twofold: they gather the requirements for the software being built, and pass those requirements clearly and concisely on to the development team. The business team acts as an intermediary between the customer and the development team. Sometimes these circles overlap, something typical when the customer is an internal entity.

The business team needs to clearly understand the requirements of the software being made for the customer. In a perfect world, the business team would be able to write user stories that directly reflect what the customer wants the software to do. Sometimes they  have to drag these needs out of the customer, a process which can be especially frustrating in cases with complex business requirements (the critical functions and processes of the software). Matters only get worse if the customer refuses advice from the business or development team about how to shape those requirements into working software.

There are a few things that the business team can keep in mind if they really want to do a stellar job, and avoid being the bug. First, they should keep in mind that the customer is not always software-competent, meaning that the customer might not know when something is the wrong approach. They need to be patient with the customer and make sure that they completely understand the customer’s requirements before they pass a half-baked set of requirements off to the development team. Finally, when writing user stories, the business team should do their best to put themselves in the minds of the software engineers.

Lets say Zark needs a filter on his website to allow customers to sort through types of bread. It’s not enough to just say he needs a filter. The XYZ business team needs to ask questions. What data is this filter accessing to determine if a particular product is applicable? Is the filter a drop-down or something else entirely? If it is a drop-down, where do the values come from? Is it a fixed list, does Zark Muckerberg need to be able to quickly and easily modify this list, or does it automatically build up as Zark adds products to his website? These questions need to be answered with the customer, and the answers need to be clear and concise for the software engineers in the development team.

The Development Team

A team of software engineers can be found at the heart of any great development team. These are the guys and gals that take the requirements laid out by the business team and turn them into a functional piece of software. Luckily, the development team never makes any mistakes, so we can skip this section.

Just kidding. As a developer or software engineer, you have the comfort of being buffered on each end of the Agile process by the business team and the QA team. Assuming both of those units are performing their functions to a high degree, your job can actually be extremely delightful. However, in cases where the requirements are lazily defined or where no one is covering your tracks with testing, it can be a painful job that leads you, the software engineer, to be the unwitting bug in the brew. Either way, it’s your responsibility to take the requirements given to you and implement them to spec, testing along the way to ensure that the requirements are met.

It is, perhaps, most important for the developer to find a balance between pride and humility. The developer needs to be extremely competent and willing to selflessly help others  to ensure the success of the project. They also need to be willing to accept criticism and able to constantly work toward improving their skill set and knowledge base. The internet has made this immensely easier, with developers no longer having to rely purely on instinct. Forums like StackOverflow and various tech blogs provide a vast wealth of knowledge for any developer to pull from.

Lastly, the developer is responsible for helping the other units of the software engineering team stay on top of their game and accountable to their output. Make sure the business team is giving you good requirements, and ensure that QA is testing thoroughly! A developer working on Zark’s website should thoroughly examine the user stories assigned to them to assess the level of detail put into the requirements, while reaching out to the business team with any questions or concerns. After implemented the stories and writing tests to cover the new functionality (or bug fix), the developer should make sure that the QA team will know this functional change needs to be tested, and that they have access to whatever tools and sample data they need.

The QA Team

The QA team is the final ingredient in the Agile brew. The QA team’s job is to test the application after the developer has made changes. They look at the requirements as defined by the business team and ensure that the developers have met that spec without compromising the application in other ways. Nowadays the developers also have a hand in this. By writing tests to make sure their code is doing what its supposed to, the developer can head off mistakes in the code. QA is more like the defensive line, there to block any issues or deviations from the spec from making it to the goal of production.

QA teams become the bug in the brew when they are either under involved or over involved in the development process. Think of it this way. The Agile lifecycle is exactly that—a cycle. The business team should meet with Zark, the customer, and examine the problems that his software solves. They should ask questions and become very familiar with the use cases. Once the requirements are gathered, they should be written clearly and thoroughly so that the developers can do their job without wasting time hunting down extra requirements. The developers should thoroughly and carefully implement the new functionality, passing it off to QA to test. QA’s feedback should be directed to the business team, allowing for minimal interaction with the developers, unless there is a question that only the developers can answer.

If the QA team clouds up development time by bugging (wink, wink) the developers too much, developers lose productivity. The lifecycle is by no means a one-way platform for discussion. It is, however, designed to allow developers or software engineers to focus on the most important tasks in front of them. Any break in that focus can be, to some degree, detrimental to the overall output of the team. On the other side of the coin, if the QA team isn’t testing the application thoroughly, disastrous issues can make their way to production, where they become immensely more problematic.

The Team Pulls Through

Zark Muckerberg came into the process with a clear idea of what he wanted. The business team examined his requirements and created a concise set of user stories to pass on to the developers. The developers implemented to those stories thoroughly, reaching out to the business team with any questions about the functional requirements. The QA team thoroughly tested the application and reported any issues, taking care to let the developers focus on their work. Now Zark has an amazing website that does exactly what he needs. The software performs these functions well without laying any unnecessary bells and whistles on top.

While it may seem like I’ve cordoned off each unit of the team and set them up for blame when something falls apart, the opposite is true. As a team, we hold each other accountable and offer support when clarity is difficult to come by. As a software engineer, I always work harder when there’s some weight on my shoulders.Here at SemanticBits I’ve been fortunate enough to always have someone to lean on when things get particularly challenging. An Agile development team is strongest when each member puts forth their best effort. No bugs in this brew.