The following article is a cross post from our sister site. It has been updated for 2020, edited for accuracy, and modified to fit the style of this site.
Teams of people need structure. Humans are imperfect, forgetful, prone to mistakes, and often cut corners for convenience or “time saving”. Yes, structure and organization are important for teams of programmers and software engineers no matter how many times your leaders have declared that you’re an Agile (with a big A) and agile (with a little a) shop.
Ask Questions during Interviews
It’s easy to get swept up in the marketing techniques that a lot of software companies use during the recruiting and interviewing phases. Maybe you’ve been eyeing a particular position for awhile and finally have the opportunity to make it through the on site gauntlet. You may also be desperate for a job for one reason or another. Regardless, it pays off in the end to make sure you’re aware of how the business operates under the hood.
These guidelines are especially important if you’re signing on as a full time employee or with a company whose primary business is something other than writing software. The former because it’s mentally more difficult to give up benefits, vacations, and a consistent salary should you find out that you’re really not enjoying the job. And the latter because businesses that focus on something other than software are notorious for, frankly, not giving a crap about their various IT/software departments.
During the interview phases of your job search, make sure to take time to ask the interviewer your own questions. Many people overlook this part of the interview phase either because they’ve been in the interview process for 6 hours straight and want to go home, or they just don’t care. From personal experience, it’s a mistake to miss out on the only time you’ll be able to get details about the business, the team, and the project that you may be joining.
Define and Enforce Coding Standards
Many times, software shops will discuss their coding standards verbally but eventually get tired of repeating it to new hires. This means that on-boarding processes are abandoned, and new hires are left to come up with their own standards which may or may not conflict with the previous verbal standards. If your shop decides on a set of standards and holds developers to those standards during code reviews, everyone on the team now and in the future will easily acclimate to the various projects across the team’s code base. This reduces friction and increases coding efficiency.
Examples of what should be standardized include:
- Comment styles and lengths
- Names for projects, assemblies, classes, interfaces, and variables
- Project architectures and structures depending on needs
- Endpoint names and structures in APIs
This list above is definitely not exhaustive, and I’m certain that you could come up with a lot more to standardize. Remember not to go overboard. You don’t want to inflict too much regulation and pains on your teams to the point that they feel incapacitated.
Code Reviews and QA Standards
Reviewing what has been checked in and what is slated to be deployed are two very important and often overlooked aspects of software engineering. I’ve worked in many software shops where there is literally no such thing as quality assurance. Instead, developers make some changes, check in those changes, do a spot check, and then immediately call for user acceptance testing or production deployments.
What’s the big deal? They’ve done a spot check, right? Even though simple projects may be OK with this sort of wild west style, more complex projects may be caught up by this “convenience” and turn into a mess. Once you start slacking off with reviews and standards, it becomes very easy to simply continue that slack until you forgot why you were reviewing things in the first place. The result is messy code, confusing project structures, and a complete loss of understanding when new employees take over older projects.
To prevent maintainability and production problems, always make sure that your developers are issuing pull requests, checking in to shelvesets, or simply asking for peer reviews prior to checking in changes to whatever branch is being changed. If your lead developers are making sure that all code standards are being met, the code base remains clean and understandable by current and future developers alike. Additionally, if an independent review is performed by a QA department, problems which were not immediately obvious to the developers and code reviewers can be found before the customer has to deal with them.
Source Control Policies
Source control is one of those super important concepts that simply isn’t taught to degree seeking engineers and programmers. It may be briefly touched upon or needed during whatever lesson plan or project is being utilized. However, the complex strategies behind branching, merging, features, tags, and comparing commits is completely absent. It’s a shame, because source control is something every developer has to deal with on a daily basis and can make or break a successful team-based project.
A team needs to decide on which source control technology they’ll be using. This is largely dependent on the number of developers, your other development tools, if your team is in house or remote, and the skill sets of the members. If everyone knows git and nobody knows svn, then the choice is obvious. If everyone knows every technology, but the team is comprised of remote developers, then a decentralized source control strategy is probably best. The only rule to the ultimate choice is that you decide and stick to it. Don’t be like companies I’ve worked for where every team uses a different technology.
Once the repository is decided, you need to come up with how the code will be structured and establish branching and merging strategies. When are branches created? Only for full stories? What about defects and blockers? Should minor features have their own branches or only major versions? Who is in charge of merging? Will you use pull requests? When are code reviews conducted for each merge? Will the MAIN or MASTER branch contain the current state of production, or will tags indicate that? These are just some of the questions you need to be asking you and your teams to manage success.
Release and Deploy Plans
There’s a really big piece of software systems which gets overlooked quite often. Guess what it is? Oh, you read the heading above, so you already know. A lot of shops and developers take this step for granted and instead opt to just “release whenever.” This is dangerous for a variety of reasons, especially as you begin to develop more complex systems with more developer and team involvement.
To be clear, if you’re just a single developer with a simple project, there’s not a pressing need for a complex release plan. It could be something as simple as, “Check in to the MASTER branch, tag the commit, and then deploy to a set of servers.” As your project becomes more complex, you may want to think of a dedicated deploy server, automated builds, automated deployments, or giving another person the specific goal of managing deployments.
For more complex projects and teams, it’s absolutely essential that you put together plan which accounts for the following:
- When do releases go to DEV, QA, UAT, and PROD? Are these environments even relevent? Cater to your specific project and team.
- How are releases versioned, built, packaged, stages, and released?
- What is the rollback plan?
- When are the standard release times?
- What is the allowable downtime?
- Are there load balanced or redundant servers which need to be updated as well?
Once you’ve established and documented the release plans, establish a process by which the plans are enforced and teams are held accountable.
Create Specialized Teams
There’s a growing trend at Agile (with a big A) shops where leaders espouse the idea of hiring “generalists.” When you push for details on that term, you’ll usually get back something like, “Oh, every employee should be able to do every job we ask of them.” That sounds good at first, but then you start to realize everyone is average at everything. Sure, your developers can test each other’s code, but is that really going to be a thorough, unbiased, and objective measure of the application functionality? Probably not. What about quality analysts handling build configurations? Sure, I’ve seen it done, but it usually ends up sloppy and sometimes wrong. The point to be made here is that teams of specialists ensure that every item discussed above is handled appropriately.
Look into creating specialized teams such as:
- Software Engineers
- Quality Assurance Analysts
- Developer Operations (Build Configurations and Deployments)
- Technical Documentation and User Manual Writers
- Business Analysts
- Project Managers
- System Architects
- Database Administrators
Keep in mind that you don’t have to hire huge teams to fulfill these roles. Even having one or two people in each role is far and beyond better than just telling everyone they are filling in for every role whenever it’s needed. Not only does this minimize the required task switching, but it gives people confidence in what needs to be done on a daily basis. Each team can come up with standards that fit their roles and then work those standards in with the overarching company standards. This gives local autonomy while persisting the company’s goals.
Involve Business Experts
Software is created to solve a problem. Those problems are usually aimed at businesses. I can’t tell you how many times the simple concept of “solving a problem” is lost on the teams responsible for creating said software. Sometimes developers get stuck in the weeds or land a never ending project thus resulting in a complete loss or the original problem being solved. Project managers and business analysts should be responsible for bridging the gap between the engineers and the business users. This includes technical to non-technical translations, gathering of business requirements, and often keeping the customers humble by understanding and suggesting improvements to the business processes.
The business domain experts who actually experience whatever problem is occurring must be involved with the design of the system’s process and user experience flow. However, they should not be involved with any technical discussion of the product. The business should communicate what they need and not how to build it. It is important to understand this distinction because a lot of developers simply do what they’re told by often pushy and impatient domain experts. I’ve personally been involved in projects where aggressive business users have demanded that a specific technology or algorithm be used simply because they “took a night class” which discussed its benefits.
Once the project managers and business analysts are in a comfortable arrangement with the customers and business users, it is important to make sure that communication doesn’t break down over time. It’s often a good idea to have check in sessions at some regular period so that the business is constantly aware of the state of the product, how user experiences are evolving, how user interfaces are presented, and timelines or blockers that may impact ultimate deployment of the product.
Perhaps most importantly, teams need to treat each other with respect and understand the frustrations that may arise on both sides. Customers want the world, developers want logical solutions, project managers are sick of changing schedules, and business analysts are confused about requirements. These are sometimes inevitable parts to a complex project that can quickly erode the trust and communication between technical and non-technical team members. Address these issues early and often.
