Stop When You Achieve Your Goal

Software engineers use many development techniques that correspond to a sub-goal of software development. For example, structured or object-oriented analysis has the goal of understanding the problem being solved, DARTS has the goal of a process architecture, and structured design has the goal of calling hierarchy. In each case a series of steps are followed. Do not be so taken in by the method that you forget your goal. This is called goals displacement. If you have achieved your goal then stop. On the other hand, if completing the process will fulfill additional goals then continue.

"Know-When" Is As Important As Know-How

Knowing how to use a technique well does not make it a good technique, nor does it make you a good engineer. The good engineer knows dozens of diverse techniques well and knows when each is appropriate for a project or a segment of a project.

When doing requirements engineering, understand which techniques are most useful for which aspects of your problem. When doing design, understand which techniques are most useful for which aspects of your system. When coding, pick the most appropriate language and framework.

Developing Great Product Management and Engineering Relationships

A healthy relationship between Product Management and Engineering is critical to build successful products. It’s also essential in creating a team where people want to work.

When it goes well, we’re two partners working shoulder to shoulder towards a shared mission. Each is grateful for the contribution of the other. When it goes badly, there’s finger pointing, ignored input, wasted work, frustrating processes, and resentment.

Here are the 4 keys to a healthy engineering and product management relationship.

Share Leadership and Credit

One of the top ways Product Managers damage relationships with engineers is by hoarding all the credit. They claim that they thought of all the ideas and make sure they’re always the ones presenting to executives, leading meetings, or announcing results. They act like they’re the most important person on the team.

Explicitly share leadership between product managers, engineers, and designers. Each role has a clear responsibility, but we all work together to share our points of view and come to better solutions together. We have different points of view, but we all know we’re on the same team working towards shared goals.

One specific way to share leadership responsibilities is through the concept of Program Lead (PL), who can be either a Product Manager or an Engineer on the team. PLs own communicating progress, establishing the rhythm for the team, and team unity. The Program Lead can be the same person as the Tech Lead, but on some teams, they are different engineers — one person is responsible for running the team, while the other person is responsible for the technical direction.

Another way to share leadership and credit is with Key Results. These are team goals that get shared across the company. We assign them to the person who contributes the most towards their success, whether it’s an engineer, PM, designer, user researcher, or data scientist.

With this system, more people get to take on leadership roles and everyone gets recognition for their work.

Include Engineers in Product Decisions

Some PMs think it’s their job to have all the ideas and do all the product thinking. They’ll go off with their designers and come up with a grand vision to toss over the wall to the engineers for implementation. If an engineer comes up with a proposal, they’ll quickly dismiss it — either out of a lack of respect or being territorial.

Engineers need to be involved and can lead product direction from the beginning of the product lifecycle. Gather input from across the company when planning a roadmap and include all the engineers on a team in research and design brainstorming at the beginning of each project.

Engineers appreciate understanding the reasoning behind product decisions. PM’s love when engineers come up with valuable ideas enabled by creative technical solutions. We know that aligning everyone on the team around a shared purpose and shared understanding will help achieve bigger and better things together.

Clarify Roles and Reinforce them with Mutual Respect

An easy way to muddle any work relationship is with unclear roles and lack of respect. PMs insult engineers by trying to tell them how the code should work, or endanger the schedule insisting on frivolous features with outsized costs.

Focus on clarity of purpose, plan, and responsibility. PMs own the problems and Engineers own the solutions. For team leadership responsibilities that can vary from team to team, go a step further and fill out a checklist so it’s clear for each responsibility whether the PM or Program Lead will take it.

Mutual respect is really in the cultural norms. Never have a PM sign an engineer up for a deadline without their buy-in. Engineers take the time to explain technical challenges to PMs and really care about the customer impact of our work. Consider providing all new employees with some training that reinforces the idea to approach situations with curiosity rather than a need to be right.

Clear Away Inefficiency and Help Your Teammates Succeed

Some engineers think that PMs just add bureaucracy and inefficiency. They’ve worked with PMs who try to solve every problem with more meetings and who burden engineers with work about work without convincing them that it’s worth it. Even worse, those PMs thrash projects in the middle because they’ve changed their minds, wasting weeks or months of work.

PMs need to be a productivity multiplier. Encourage them to look for every kind of creative way to help our teammates be more efficient and effective. Develop a product process to ensure everyone really understands the customer problem you’re going after and are all on the same page about goals at the beginning to avoid unnecessary changes later.

Healthy relationships between PMs and Engineers are critical to the success of any project. With shared leadership, inclusive decision making, mutual respect, and a commitment to helping each other succeed, you can build a team that delivers results and attracts great people.

Software Tools Are Expensive

Software tools can be expensive. You have to factor in the cost of the tool, the hardware to run the tool on, and the training of your employees to use the tool. But consider the higher costs of not buying the tools. Lower productivity, higher probability of customer dissatisfaction, delayed product release, increased rework, poorer produce quality, etc.


Reference:
Huff, C., "Elements of a Realistic CASE Tool Adoption Budget," CACM, April 1992.

Give Software Tools To Good Engineers

Users of software tools become more productive. However, a tool cannot convert a poor software engineer (one that produces code that is unreliable, incomplete, and so on) into a good one. Thus, you want to give tools only to good engineers. The last thing you want to do is to provide tools to the poor engineers: You want them to produce less, not more, poor-quality software.

Use Tools, But Be Realistic

Software tools can make their users more efficient and should be used. Remember that the hard work (the thinking) is not done by the tool. Use tools but be realistic concerning the effect on productivity.


Reference:
Kemerer, C., "How the Learning Curve Affects Tool Adoption," IEEE Software, May 1992.

Technique Before Tools

"An undisciplined software engineer with a tool becomes a dangerous undisciplined software engineer."

A software engineer must first understand and be able to follow an appropriate software technique. Next, must know how to use the tool before using a new tool.

Software engineers should first attempt any new software techniques by hand to convince their self and their management that the technique before investing time and money in tools to automate the technique. If the technique doesn't work without automation, it won't work with automation.


Reference:
Kemerer, C., "How the Learning Curve Affects Tool Adoption," IEEE Software, May 1992.

Different Languages For Different Phases

"The industry's eternal thirst for simple solutions to complex problems (Every Complex Problem Has a Solution) drives many to declare that the best software development method would use the same notations for software representation throughout the entire development life cycle. Since this is not the case in any other engineering discipline, why should it be in software engineering?"

"Notations provide us with models that can be manipulated in our minds. The more notations and the richer and more diverse the representations used, the better we can visualize the product under construction."

For requirements engineering, select a set of optimal techniques and languages:

• Use the Right Techniques
• Use Multiple Views of Requirements

For design, select a set of optimal techniques and languages:

• Evaluate Alternatives
• Design Is Multidimensional

For coding, select an optimal language:

• Use Appropriate Languages
• Programming Language Is Not an Excuse

"Transitions between phases are difficult. Using the same language doesn't help. On the other hand, if a language is optimal for certain aspects of two phases, by all means use it."


Reference:
Matsubara, T., "Bringing up Software Designers," American Programmer, July-August 1990.

Record Your Assumptions

"We make approximately one assumption every 10 lines of code, or even if I'm off by a factor of 2 or 3, one assumption every 20 to 30 lines of code." - Manny Lehman

These assumptions about very complex software systems and environments result in unexpected behavior.

Keep track of all your assumptions throughout requirements planning, design, coding, and testing. Also, record the implications of each assumption - where in the product does the assumption manifest itself? Isolate such implications by encapsulating each assumption.


Reference:
Lehman, M., "Software Engineering, the Software Process and Their Support," Software Engineering Journal, September 1991.

Every Complex Problem Has a Solution

"To every complex problem, there is a simple solution... and it is wrong!" - Wlad Turski

Be highly suspicious of anyone who offers you something like, "Just follow these 10 simple steps and your software quality problems will disappear." Or, "Subscribe to our software services and all your monitoring, logging, debugging, etc problems will be solved."

For your interest, Turski's quote is a simplification of the following quote by H. L. Mencken.

Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong.

• "The Divine Afflatus" in New York Evening Mail (16 November 1917)