Product prioritization is very complicated. There are many variables that need to be taken into account to figure out what to build and in what order. Unfortunately, it seems that cost isn’t taken into account often enough. Perhaps at most the superficial cost is considered, but cost can be a deep and complicated concept.
Types of Cost
Direct “Bottom Line”
- Salaries of engineers * time – This is the superficial cost. Pretty easy to calculate
- Hardware cost – An increase in load might require more hardware to handle more requests. Implementing an open source system like ElasticSearch, Hadoop, Redis, etc.. requires extra hardware to run on its own. “Big Data” processes tend to require a lot of hardware. Complicated algorithms can take a lot of CPU time and might require more hardware.
Indirect “Blood and Sweat”
- Opportunity cost – Your engineering resources can be building other things. While this seems obvious, at a larger company an engineer can be working on almost ANYTHING on ANY team. Product owners tend to only prioritize within their team, but a resource could be used on another team to build something else.
- Technical debt – Almost anything that is built (especially in a rush) will have some technical debt around it. As time goes on, the debt gets worse and everything gets harder to build on and maintain.
- Pager pain – You rushed a system out the door. It works, but it is held together with scotch tape. That system breaks every other night at 3 am and causes pager alerts. Clients don’t notice, but the engineering team sure does.
- Engineer sadness – Building annoying features can add up on engineers. You keep dumping on them, they will leave.
While the “bottom line” cost is fairly direct and measurable, the “blood and sweat” cost will cause engineering quality to go down over time and lead to engineers leaving. This indirect cost in the long run can be more expensive than the direct cost. Please think about these costs the next time you are doing product prioritization!
I find it funny how people confuse the concepts of “compromising” and “yielding” . When you google the word compromise, the definition that comes back is “an agreement or a settlement of a dispute that is reached by each side making concessions.” A lot of times in a work setting if there is a dispute or disagreement where there is no clear correct answer, management folks will tell the parties to compromise. But often people will call the settlement a compromise when in fact it is nothing of the sort. Here is an example of a compromise and a yielding.
During scrum planning, an engineer wants to spend some extra cycles refactoring some code. The product owner wants to spend those extra cycles building a feature that has been promised to clients for a while. Solution
The product feature gets prioritized this sprint but next sprint double the amount of time is allocated towards refactoring pushing off other product features.
Time was allocated to build user libraries for an app. An engineer wants to build the first library in python since most clients use python. An internal team would like the engineer to build the first client in Java because they use java.
The java library is built to gain favor with the internal team.
Do you see the difference? There is nothing wrong with settling an argument with yielding. Sometimes someone has to make an executive decision, there is political pressure, or there is just a best choice. However, I see no good reason to call it a compromise. I guess saying something is a compromise makes the party yielding feel better about themselves. But to me that misuse of the term is just insulting a person’s intelligence. Transparency and honesty will make people feel better than trying to play a mind trick with them.
I remember when I first started out as a software engineer in 2006 I had to “earn my stripes.” I did as I was told, learned from my elders, and tried to make suggestions here and there. If my ideas weren’t good I was told why and would either go back to the drawing board or move on.
Something has changed with the paradigm of management and engineers. It seems management is afraid to offend or bother engineers. Nobody wants to say “no” to an engineer anymore.
We allow engineers (generally junior ones) to
- Design overly complex systems
- Use random languages or frameworks
- Go against team agreements
- Merge code without reviews
- Be rude to their fellow employees
- Make inappropriate and sexist jokes
- Become “brilliant jerks”
Why are we afraid to stand up? I guess engineering talent is at such a premium that we don’t want to lose engineers. But guess what? A bad seed will make other engineers leave. Not only that, the bad seed will probably leave at some point anyway and someone will be left with the mess.
Be logical. Sometimes you will agree, sometimes you will disagree. Sometimes your opinion will be swayed by a good argument. But don’t be afraid to say no. You’re running a team, organization, or company and not a hippy commune.
A good chunk of America stuffs their face from Thanksgiving until the end of December. Some large percent of these chubbers decide to make a New Years resolution to go to the gym more, lose weight, get into better shape, etc… This yearly ritual makes January the busiest and most annoying time at the gym. Here is some advice for the resolutioners to be less annoying to everyone and possibly be more successful.
- Plan a routine and schedule. Go to the gym for an hour for three days, then take a day off, then repeat. Go at the same time each day. It will become a habbit
- Use weights and do cardio. Whatever your goal is, both weights and cardio will help you be healthier.
- Start simple. Blogs, message boards, and your idiot cross fit friends will tell you how you have to squat and jerk and clean and back flip. While those lifts are great, you are just starting out. Do simple stuff that you recognize. Use machines at first and slowly work in some free weights.
- Don’t hog anything. A gym only has so many free weights, so many treadmills, and so many benches. Do your exercise and move on.
- BENCHES ARE FOR BODIES. Don’t be that guy or gal that leaves a cell phone on a bench just to stand next to it. I don’t care if you are exercising next to the bench, unless your body needs the bench for an exercise let someone else use it
- Fancy outfits don’t help. Maybe get a good pair of sneakers. Your $500 lululime pants won’t make you run better or give you more strength. It will just make you look like snobby. Just get something you can sweat into.
- Toe shoes are useless
- Don’t do weird stuff. Yes the treadmill goes to 10 mph. Yes you can tie a weight to your waist while you do exercises. Yes you can add a free weight to a machine rack. Yes you can hang from the chin-up bar and do crunches. But WHY WOULD YOU? STOP BEING WEIRD. YOU WILL HURT YOURSELF
- Stop staring in the mirror. Yes, right after you lift your muscles look bigger. You own a mirror at home. Nobody wants to see your belly no matter how ripped you are.
- Eat better. Diet plays a large factor in gaining muscle and losing weight.
- Keep at it. Just keep going to the gym. Things get easier and feel more natural.
Good luck and stay away from my boxing bags
Sorry if this is a rant.
But then it got weird. I suppose UI engineers have been locked into client side work for too long and found Node to be their escape into other worlds. People started using it to solve every technical problem – load balancing, code deployment, crontabs, system scripts, build tools, etc…
- Node makes things too easy. There are a load of libraries easily accessed via NPM. The event driven model makes the concurrency problem abstracted from the developer so they can develop “scalable” applications without thinking too much.
One of my favorite natural phenomenons is the pendulum swing. You pull the pendulum back and let go. It swings to the complete opposite direction and then back and forth slowly decreasing the distance until it settles in the middle. The most amazing part is that so many of our decisions are modeled the same way. We react to problems by going in the complete opposite direction. I’ve experienced this time and time again in life, and I’m sure you have too.
Years ago typed languages were king. Then it was seen to be too cumbersome, so we started using untyped languages like PHP. Later we see those code bases as nasty so now we are moving back to typed languages that are inferred or duck typed.
Early on, companies would say engineers are too expensive and then outsource all engineering. Then when that failed they moved most of the jobs back. Now some jobs are outsourced and some aren’t.
Relational databases weren’t meeting the development and scaling needs because they were too rigid and structured. Many people jumped ship to NoSQL databases where there is no structure at all. But then NoSQL databases had problems of their own so now people are looking at NewSQL databases, which is somewhere in the middle.
Monolithic applications are hard to maintain, develop on, and deploy in a large organization. So now people push for micro services, which are many tiny applications. But people are seeing very different problems with that architecture.
Think about a hard breakup you had. The next person you dated was probably the polar opposite of your ex. Chances are that wasn’t the perfect person either.
We tend to react to things not being perfect by going in the complete opposite direction. It seems that a better reaction would be to slightly correct course and actually address the problem at hand. Be “iterative” or whatever the kids call it these days. The next time you are in a meeting about architectural changes or re-organizations think about whether or not the change is a pendulum swing.
Sometimes it feels like junior engineers and product folk don’t quite get what technical debt is. Actually, they understand what the term literally means but not the impact. Here is a little fun analogy to help.
Imagine you live with your spouse in a nice tidy apartment. You receive a call about a job interview for a position that is double your current pay but you have to interview right away. So you turn your closet inside out looking for your best interview outfit. Shoes, clothes, etc.. strewn around your apartment. You’re dressed to your best but your apartment is now a mess. Since you are in a rush, you leave everything and head to the interview. While you are at the interview, your spouse comes home and trips on a pair of shoes you left out spraining his or her ankle.
The best case scenario is you get the job, but now you have to take care of your spouse and clean up the apartment. It’s more likely that you didn’t get the job, your spouse is livid, you and your spouse need to clean up the apartment, and you now have to take care of your spouse.
Technical debt is the mess you leave to hopefully make some extra money off of a product feature. The mess you make is in code and not in your apartment. It can lead to bugs and outages. Messy code and systems can be hard to maintain and build off of. Each subsequent product feature becomes harder to build. Engineers get angry dealing with a mess so they leave. The next set of engineers cannot navigate the mess so they are constantly angry.
The thing is, if you had texted your spouse to leave a warning about the mess and cleaned up right when you got home from the interview, everything would have been okay. It’s the same with technical debt, sometimes you need to make a mess but if you actually plan for it and clean it up, you will be okay.
Try to avoid technical debt. But we all live in the real world so if it is necessary, pay it down quickly.
I got some interesting email feedback from this blog article. The article was generally geared towards somewhat mature startups / tech companies. Fledgling startups in the early phase need to sprint to the point where they have customers and technical debt is a necessary evil. The prettiest code ever is useless if there is no one using the product. As time goes on and customers come in, you need to start paying down debt. It’s kind of similar to processes – at first you will be horrible with process but as your teams grow and the company becomes real you will need to keep improving until everything is seamless. Just as a warning, some bad technical implementations can actually get exponentially worse if left alone for too long.