“Speaking programmer” is a valuable skill to have as a project manager, entrepreneur or anyone in a managerial position. This is the manager whose butt is on the line regarding the successful delivery of a software development project. Before you chuckle to yourself as a manager, know that we have a similar blog post called “How to Speak Manager.”
Successful communication between managers and developers boils down to mutual understanding of expectations. Skill and decision making play a big part in success, but poor understanding of expectations is likely the most common cause for failed development projects.
To better manage ongoing expectations, projects should be broken down into critical milestones within key phases of the project. The phases are often referred to as SDLC, or Software Development Life Cycle. The most important phase is the first, Requirement Gathering and Analysis. Below is an example SDLC:
- Requirement Gathering and Analysis (When the manager and programmer research and discuss the requirements and then agree on goals)
- Design (When the programmer determines how the solution will be built)
- Implementation or coding (When the programmer does the actual programming)
- Testing (When the manager and testing team confirms the software performs as expected)
- Deployment (When the software is moved into production for use)
- Maintenance (When the software is enhanced, minor bugs are fixed, etc.)
Below is an example of a FOO*lance job bid, with milestones for a smallish website development project.
Communication is critical for the first phase, requirement gathering, and analysis
The requirements gathering phase is arguably where the most important communication takes place. This first milestone should include not only specifications and research, but also an agreement on goals. This means research should result in additional discussions to adjust mutual expectations in light of what’s discovered. By then end of this milestone, the managers and programmer need to understand each other’s expectations and be committed to the same goal.
Don’t skip phases of the SDLC, especially the specifications
A common mistake by managers is to not include a formal step in development for specifications, discussions, and commitment to goals. This process takes time. It needs to happen one way or another for success - so doing it at the beginning as a formal step is smart. Skipping this step is not how to “speak programmer.”
Take a whack at writing specifications
Learn how to write specifications that do the trick for the programmers you work with. Get their feedback and involvement as you learn how to write them. Specifications don’t have to be perfect to be really helpful. Different programmers like different levels of specification.
Communicate your business purposes and use cases
Specifications should also include the business purpose of the software. Managers need to own this part of the specifications. This is where a manager explains why the software is needed. Business use cases offer real world examples. Each case shows how the software would be used and how it supports the business goals. Don’t get caught by the common misconception that programmers don’t understand business. This is a give and take discussion. The manager needs to be clear with their business cases and the programmer needs to explain the options for a solution.
It’s more work than you think - that’s why things take longer than expected
Remember, projects always take longer than everyone thinks. Keep things simple, and don’t take advantage of a programmer's commitment to deliver. Work together to set reasonable deadlines and make adjustments if things turn out to be more complicated than anticipated. Don't glorify all-nighters.
There are no free shortcuts
Listen to a programmer when they caution you not to skip steps or to not take shortcuts. Programmers take pride in their approach, and cutting corners is often hard for them. They see the future, including the mess everyone will deal with later when taking shortcuts.
Change is painful
Avoid making changes after the specifications phase. Changes are hard to navigate for programmers. Changes can often create so much work that it’s harder than starting from scratch.
Scope creep is different from change, but can be equally cumbersome. This is when items are added to the project after everyone has agreed on goals. Scope creep is rarely as incrementally small as people think and can disproportionately slow progress and delay completion.
Here are the takeaways
- Speaking programmer is an exercise in common sense, listening, give and take, and articulating what’s needed. Highlights include:
- Don’t skip steps in the SDLC.
- Never skip the specifications step, and include your business reasons with the specification
- Specs aren’t done until you have a mutually agreed upon goal.
- Listen more. Assume less. Clarify often.
- Programmers understand business more than you think
- Avoid scope creep, both yours and the programmer’s
- Balance what you want with what you need and what you’re willing to do for the common goal.
- Don’t change the specifications once you’ve committed to a goal.