Finding Harmony in Development Pt. 1
- October 29th, 2011
- Posted in FHD
- By Michael Blake
- Write comment
Before reading part 1, you might want to check out the Finding Harmony in Development Primer.
Warning: All of the following statements, along with the additional entries I’ll make on this topic, are based on personal experience only. While experiences may vary drastically, this is my viewpoint on how development teams can be organized in a manner that will provide the best results and cause the least amount of friction. Opposing opinions are extremely welcomed. This is the first part of a multi-part series.
A development team consists of many parts, and part 1 of this series is going to be dedicated to defining those parts and talking about their traditional functions. The next section will focus on altering those traditional functions to fit more inline with my viewpoints on the proper structure. In the third part we’ll talk about creating a frictionless transition from the traditional to the non-traditional.
Sometimes multiple parts of these functions will be performed by a single entity, in these cases treat them as two distinct job descriptions being performed simultaneously.
Now, the functions of a software team, in the order their responsibilities will be covered is:
The User
Software is not often built on the premise of pleasing yourself. Software is developed for use by an end user be it other software developers, internal members of your company or consumption by the public at large. There is always a target customer for software production of any kind.
There are two ways in which customer interaction can be performed. The first is through a user advocate, which is ideal when you are dealing with a piece of mass consumption software while the second is through direct contact with a stakeholder. The interaction should not vary much between the two. Both speak for what the product is designed to do, the goals it needs to meet and what defines a finished product.
Product/Business Analyst
This person or team is responsible for interacting with the Stakeholder and turning concepts into actionable items. Their job is to somehow get a stakeholder to understand what they want in terms that can be turned into software. It can be an extremely difficult balance.
One of the primary differences between Product teams and Business Analysts are that Product tends to operate independently from the software development team, acting more like a think tank in some cases, while Business Analysts generally exist as part of the development team itself, providing a friendly face and a users outlook to development teams.
Software Developer
The role of the software developer is fairly straight forward. They take on the specifications of the product team and translate them into logical code. Where the difficulty can come in is that a manual process is often full of vagueness and indefinites. Computers don’t understand stories like “Evaluate length of customer contract vs. unique circumstances”. Everything a programmer works with must, almost by definition, be quantifiable.
In addition the Software Developer provides tested code and works to improve the development process to increase efficiency and throughput.
Quality Assurance
QA is one of those hard to define portions of the process. There are different definitions and concepts that all fill the same general position in a software team.
Generally the responsibility of quality assurance is to ensure that all the necessary requirements of the software as met as well as the esoteric concerns like usability,
In many ways Quality Assurance can be seen as one of the most complicated tasks on a software development team, requiring both left and right brain thinking.
QA Engineer: The QA Engineer is a subset of QA, generally focused heavily on automating tests and minimizing the usage of manual tests. QA Engineers are a more heavily technical style of QA.
Manager/Architect
A manager handling a software team is in the unique position of having to handle the friction between team members with very different goals.
While technically the whole teams goal is to create software people want to use, it is not uncommon for the business units in question to come in to conflict. When this occurs the manager must handle those conflicts keeping in mind the singular goal of producing the highest quality software that they can, regardless of who wins or loses in a disagreement.
###UPDATE###
Infrastructure
These are the guys and girls who give you the servers you need to move between environments. Their responsibilities might include picking what linux you use, managing your firewalls and generally serving those tech needs that require a deep understanding of concepts like network management and host level access.
Data
No, not everyone’s favorite android.
The data team often handles schema definitions, database backup schedules, permissions and indexing along with a number of other details. A database administrator can provide a wealth of knowledge on performance tuning at the data level, along with providing quick access to statistics and measurements that the business units will find extremely helpful.
Design:
Designers, how could I forget them? They make the work we do beautiful. Designers are generally creative people who have a huge influence on what goes on an individual page, and how it’s placed. Their work can be key to the success of a project, especially a commercial project.
Designers often write the markup and CSS key to web applications, and even .net desktop applications have found a place for full time designers with applications like Expression Blend and frameworks like WPF.
###END UPDATE###
In Conclusion – But not really
Even this short list of what the core team does (and I get the nagging feeling I missed something) is running a little long. Keep in mind these descriptions are by no means complete, and cover only the most basic of job functions.
In the next part I’ll talk a bit about modifying these traditional roles. My original hope of keeping this to a three part series might be a little optimistic. We’ll see where it goes! If you feel anything is fundamentally missing please let me know so I can consider adding it as we get into the series.
No comments yet.