When developing enterprise software products for internal or external use at a business, there are things that developers and team leaders need to advocate for their teams. There is a constant back-and-forth between development teams and stakeholders, a dance that balances business desires for speed and accuracy against developers’ need for time to take a systematic approach. While stakeholders push for quick delivery and minimal revisions, developers advocate for sufficient time to ensure quality, maintainability, and long-term efficiency.
In the military, there is a saying, “Slow is smooth, and smooth is fast.” In software development, it may be more accurate to say, “Methodical is smooth, and smooth is fast.” Many aspects of development sound like they will add time to a project for stakeholders, but in the long run, they will save developers time. This means they can develop more great solutions for business users.
Leaders on development teams must stress to stakeholders that these elements will save time and money in the long run. Ultimately, software departments should optimize for long-term ROI and work to support the business needs, not oppose them.
- Standards
- Rigorous requirements gathering
- What to do when scope creeps
- Code reviews
- Testing
- Staying up-to-date
Standards
A lead developer’s need to advocate for a good set of standards across a department or team stems mainly from the incredible productivity gained by team members being on the same page. When projects have a consistent structure across teams and departments, there is no costly digging through files trying to find things to make small changes. It ensures small changes take a small amount of time.
In addition to allowing developers to work faster, consistent standards and project structures enable senior developers to assess the time required to complete a project more accurately. It also offloads higher-level design decisions to more experienced developers so that each developer can focus on the tasks in front of them, no matter their level of skill or experience. Teams benefit hugely from having a high bar set by a company’s minimum standards. A good set of standards, which is an investment, may require time up front, but the cost savings in the long run come in several ways and can be tremendous.
Initial Requirements Gathering
It may seem obvious, but it is often necessary to remind people that the better a team gathers requirements upfront, the less work the project will require in the long run. Gathering accurate requirements ensures that projects are estimated accurately, and developers must be mindful that this is critical to the business. The goal of gathering accurate requirements is to minimize scope changes down the road; the later in a project’s life cycle that significant changes are required, the more expensive they become for the business. While we want to gather accurate requirements, the benefits of this are asymptotic, and changes will almost certainly be required down the road; the goal is to minimize these. We also do not want to get locked into a mode of analysis paralysis where we keep gathering requirements and push off working on a project. Some great tools for gathering requirements include collaboration with users via interviews to determine their workflow needs, creating user stories and wireframes, and more.
When developers meet with business users to determine their needs, business users must have some technical representation, and this is where good Project Owners (POs) come in handy. Their job is to determine, along with developers and business stakeholders, precisely what is needed and delineate needs and wants on a given project. They bridge the technical and business sides, ensuring the project meets both requirements.
What to do when scope creeps
While gathering requirements helps mitigate scope creep, it can rarely eliminate it. If teams could look into a crystal ball and gather requirements with 100% accuracy, they absolutely would. When things come up from business users, POs and developers must draw a clear line between features/changes needed for initial release and features/changes that can be added later without affecting the project’s efficacy & efficiency. Early prototyping can be a massive boon in preventing scope creep and should be advocated for by leads whenever possible. The sooner users have a tool, the sooner they can have the “aha” moments where they realize something was missed in requirements gathering. The earlier teams can catch these, the more minor their impact on the project’s scope. For instance, if a relationship between two foundational entities in a project needs to be changed, catching that during database design will result in a change that probably takes 10 minutes to make. That change may require days or weeks if it isn’t seen until just before release. (Or worse: after?)
It is also essential for leads to remember that when confronted with scope changes, what stays, what goes, and what gets pushed back are business decisions. Development leaders are responsible for equipping business stakeholders with everything they need to make informed decisions. That said, it is essential that when the scope increases, development leaders advocate for the time necessary to complete the requested changes.
Testing
It is hard to understate the importance of planning into a project’s life cycle and the time required to test things thoroughly. In project planning, leads should go forth with the attitude, “Absolutely, we can do X, but we need to make sure we add tasks for testing as well.” Testing can be a time-intensive and sometimes tedious process; therefore, good standards are foundational and crucial for timely development. This empowers developers to write tests quickly, with clear expectations about how they should be formatted and what they are testing for. As stated above, users should participate in this process as early as possible. Their involvement in the testing process is crucial, as it can uncover potential scope changes much earlier in the development process, meaning changes are much cheaper.
To accurately estimate the time required for testing, leads should ensure the necessary time to make required changes, and fixes is baked into the estimates. Leads should also remember that testing should be proportional to the criticality of a given project. For example, the tests required for software used in a NASA launch are much more exhaustive than those needed to release a game like Flappy Bird.
Code Reviews
One final thing that team leads should advocate for is planning time to review developers’ work. Even senior developers should have their work reviewed by peers because nobody is perfect, and everyone can continue to improve. Code reviews allow a company to invest in one of its most important assets: its developers. They ensure that quality code is written and that their developers are regularly exposed to growth opportunities. Code reviews also do wonders to ensure that leads can clearly understand where their team members are, their strengths and weaknesses, and maintain a transparent mental model of what the team is doing.
Security and Package Updates
It cannot be understated how catastrophic and potentially destructive breaches are to companies, especially companies specializing in software. A large portion of updates that come out for packages tend to be security-related. One of the best ways to mitigate breaches and ensure that software is as secure as possible is to set aside time in planning for teams to review the projects they own — and every project should have an owner — and ensure they keep their packages and dependencies up-to-date. This is one of the areas where technical debt can accrue the fastest; it is way easier to keep projects up-to-date than it is to catch up.
Keeping packages and dependencies up-to-date is generally not an overly time-consuming task, and great tools are available for every language and framework. It can even be built into a team’s linters or deployment pipelines.
Finally
A team leader’s job is to communicate to business stakeholders clearly and equip them with the information they need to make informed decisions. All of these should be advocated by development leads to stakeholders because, in the long run, all of these will improve the business’s bottom line. Sometimes, development teams can get lost in the process, but it is essential to remember that the purpose of building software is to drive the bottom line of the businesses they are used by.
