Software Development: Managing for Success

Fear can keep companies from using software to solve business problems. Stories from past projects can make programming seems like magic – and just as hard to evaluate. Below are tips to manage risk and plan for success.

Carefully Check Whether Each Deliverable Works For You

There are always fewer highly productive developers than the economy requires, and hiring them is best done by … another developer.

However, everyone is qualified to evaluate a development team’s work, and specifically, how/whether it solves their business problems. Our clients start by clearly defining what they want us to build. If they find it difficult to define it in a way developers will understand, we may have them spend some time either refining their specifications or having a business analyst help them with the task. At the end of each “sprint” (usually a two-week period), they receive updated code. As they give clear feedback on each deliverable, they help keep the team on track.

To plan for success, set aside sufficient staff time to fully assess each deliverable in time to provide input for the very next sprint. Your “user acceptance testing” (UAT) is a crucial part of the process.

Work With Your Development Team On Bugs

Bugs are common in all software ecosystems. Developers hate them, and want to collaborate with you to identify and fix bugs to make your applications robust. Instead of simply checking whether your software loads/opens, use it aggressively, and promptly file a separate issue for each problem you find.

A thorough issue description earns developers’ respect and enthusiasm. You can probably guess what not to do, but here are a few tips:

• When a developer is working on your issue, they may have further questions for you. Please answer these promptly. It’s likely that the relevant part of the code is “open” and being worked on right now. If you delay answering, they will move on to the next bug, with a consequent productivity hit as they’ll have to open up that section of code again in the future.

• Vague problem descriptions lead to developers feeling confused and demoralized.

• Worse than useless (from a developer’s point of view) are: sending bug-related notes in a Word, Excel, or PowerPoint document; mentioning problem details in phone or email messages but without the ticket number; calling a team meeting and telling all the developers about a bug that only one of them will actually be working on.

To specify the order in which issues are fixed, you can set a severity/priority level for each issue you create (and issues found by QA as well). As an example, a database error upon login that blocks further testing should be High or Urgent. A visual glitch that doesn't block testing can have a lower priority.

When you feel particularly strongly about a bug, best practice is to file a complete issue description with screen captures or other examples, assign a high severity/priority, and then include the ticket number in an urgent email or phone call. Once we know that ticket 7334 is radioactive, with a bullet, the information to reproduce and start work on it will be right where the team needs it.

Manage Tech Debt

Also called “software entropy”, technical debt refers to the idea that when code is not completely finished (or the users’ needs change), the developers’ time spent updating and maintaining the existing codebase eventually becomes more than it would require to write fresh new code.

Some “tech debt” makes sense in a first release, where the goal is to get reactions from users, then smooth and streamline and optimize. Address long term tech debt by upgrading and/or rewriting your software, module by module. Prioritize the most critical (or most creaky) parts first. Based on the results from the first few modules, fine-tune plans and repeat. The most risky approach is to ignore the issue.

Part of planning for success is to manage tech debt in a way that suits each individual project. If in doubt, ask the development team for advice on approaches to this.

Make Device, Browser, and Platform Decisions

Developers should be able to explain the implications of these choices without condescension. Rely on their expertise and understanding of trade-offs.

Many companies reduce risk (and tech debt) by polishing their software on just one platform, before rolling out on all their target devices.

Maintain Control

At the beginning of a project, control consists in specifying precisely what needs to be built. Most teams will ask for the user stories or “jobs” the software will accomplish:

User story: Find the nearest (nouns) in my price range.

Job: When (event: customer’s GPS indicates they have moved more than N units), I want to (event: notify the server), so I can (goal: continue to serve location-specific data).

It’s also key to provide a description of all the kinds of data that the code will be working with. These and other system specifications can be used to develop an estimate (expressed as a range of development hours) for each of the chunks of work.

More control can be exercised in the choice of which chunks will be built, or which will be built first. Hours spent per ticket or feature appear on invoices, allowing for cost tracking. Finally, as noted, carefully specifying the priority of issues to be fixed allows your project to be wrapped up cleanly.

Planning how to address these issues will reduce the uncertainty in your software development projects and make it easier for you to manage them to a successful outcome.