Reading Guide for Software Estimates

Business, Technology

We’ve all been there. A lot. Before your next argument about a project estimate starts, take a minute to get everyone on the same page. Estimates are in important part of business AND estimates are often wrong. Yes, both of these truths can exist in the same universe!

My favorite insight from this set of articles was from John Cutler, “What job are you hiring estimation to do?” This perspective is perhaps the most valuable thing to keep in mind as your team works through your next estimate.

The Cost of Supporting New Features

Business

Everyone wants more features.

It’s like a car that has a toaster and a rocket engine. Sometimes that can totally make sense.

Plenty of people have covered the dangers of new features and I’m not going to talk about that the cost of building new features. Let’s assume that the new features are important for your market. What I want to talk about is the cost of supporting new features. Say you have a development team of ten. What percentage of that team is available for new development and which need to hang back on bug fixes and minor improvements?  At GoReact we’ve been able to maintain a sub-25% bug allocation for the past two years and we’ve really felt free to work on functionality that’s good for new customers and partnerships. But even with 75% of our resources we haven’t churned out 75% new features. Pointy-haired boss is wondering why at this point, right? Let him wonder. You will always have work in a couple of areas and your ability to anticipate and manage those pipelines as the needs ebb and flow is a critical piece to continued success with development projects. For me this means balancing the bugs, new features, internal projects and changes.

Kudos to the Phoenix Project for making this approach available for the general masses. It took me a year to read this book after a friend and coworker recommended it, and I regret that I lost an entire year of this perspective. It’s now required reading for my team and I keep a fresh copy at my desk for any new-comers. The sooner you understand what is really happening and what is really needed to run year after year, the sooner you regain the reigns on your team’s ability to really make the business move.

Those of us who have been around the block a few times know the pitfalls that come with maxing out development on new functionality. Don’t get me wrong here, I’m talking about sustained focus, like years.*  After huge pushes like this you can turn around to find out that your existing customers are leaving you because their product–the one that you built last year–is falling apart. Almost all of the time this is a bad thing, so unless you’re pivoting your product to a new market and pretty much leaving the old one behind, you’d better run some quick calculations.

Now here’s where I get a little fuzzy, so you’ll have to finish these equations out for yourself

Your velocity for new development (Vn) is what’s left over after you subtract velocity wasted on bugs (Vb), spent on changes (Vc) and invested in internal projects (Vi). In my experience the internal projects are usually small and pretty easy to prioritize where they support Sales, Marketing or Support. Hint: one of those is a cost center. That leaves bugs and changes.

This simple little ditty came to me during a daydream I had while in a product meeting. I’ll walk you through it and then we can have a good laugh about it. Your change velocity (which is refactoring, rearchitecting, server and configuration changes) can be calculated by examining the size of your code repository (R), multiplying that by the sum of the features that Marketing (Fm) and your customers (Fc) think you have and then you multiply that by the number of people on your Sales team. Then you divide that by the number of QA (Eq), product (Ep) and developer employees (Ed) on the team.

The equation for bugs is pretty similar but the numerator is your repository size and the number of features you actually have. This is all tongue-in-cheek but either way it seems like these are the only hockey stick graph (exponential growth) the product development team every sees!

Alright in all seriousness, we know that:

  1. Bugs are best mitigated by talented QA team members and a development team absolutely devoted to testing. We’ve saved ourselves a lot of customer heartache by ensuring that our code is the best possible quality and we attribute that as the reason our customers stick with us so long, second only to product-market fit.
  2. Changes increase as the code and features increase. This part is actually pretty simple math, but never ignore it.

We also track the velocity ratio between our top projects and what we call our “tribute” work. The latter for bugs, small UI tweaks, very minor updates and any out-of-band refactoring. We’re holding at about a 3:1 ratio. This means the next four hires are only going to give us three heads to focus on new projects.

Here is the real key: find your ratios and plan for those as you make hiring decisions.

  • Understand how much of your time is spent in each of your types of work
  • Understand what the business really needs in each type of work
  • Understand how the ratios can change as you:
    • Add more features
    • Add more code
    • Refactor for reusability and modularity

—

* I have to qualify something here. Sometimes teams start to feel some burnout after huge pushes and new features are often the scapegoat. There is a whole area of discussion around helping your team understand why new features are necessary and why bug pushes can be critical for a company’s success. There are also horrible stories about how managers misuse “death marches” and fail to do necessary research and justification for their projects. These big, hard projects can be a harbinger for the death cycle but they can also be just what it takes to succeed.  If you’re in a position to question your company’s approach, I feel very strongly that it’s always on you to get your questions answered and either alleviate your concerns or confirm your suspicion.

I loved Good to Great and although it’s getting dated the principles keep coming up.

Companies that fall into the Doom Loop genuinely want to effect change—but they lack the quiet discipline that produces the Flywheel Effect. Instead, they launch change programs with huge fanfare, hoping to “enlist the troops.” They start down one path, only to change direction. After years of lurching back and forth, these companies discover that they’ve failed to build any sustained momentum. Instead of turning the flywheel, they’ve fallen into a Doom Loop: Disappointing results lead to reaction without understanding, which leads to a new direction—a new leader, a new program—which leads to no momentum, which leads to disappointing results. It’s a steady, downward spiral. Those who have experienced a Doom Loop know how it drains the spirit right out of a company.

 

Eyes wide open. Success is predicted and planned for.

Vehicles for the Tall

Reviews

If you’ve met me then you’ll understand why shopping for a vehicle takes on an extra level of effort. At 6’7″ I don’t get all the headroom that I’m constitutionally entitled to which is an outrage! No seriously, tall guys get left out of a lot of great cars. For a positive spin, there’s a lot of horrible cars that I didn’t even have to consider, so I guess that’s nice too. So when I set out to get a new car, I knew that it would take some effort to find something that would work. I’ve driven a Prius, the Ford Expedition and several Honda Accords in the past, but it’s high time I got something that was made for a big boy. Here are some key takeaways from my research worth calling out:

  1. Of all the trucks, only the F-150 was tall enough
  2. SUVs don’t really offer more space than cars
  3. Man, there are a heck of a lot of SUVs that are basically the same!
  4. There aren’t enough Subarus in Utah

As I am want to do, I created a spreadsheet to help me refine down the list of cars, trucks and SUVs that I’d have to sit in to know if they’d fit. Dealing with dealerships and salesmen isn’t my favorite pastime so I wanted to keep the in-person stuff to a minimum, although it is SUPER important to make sure that you’re comfortable with AND in your new car before you buy. Here are the factors that I looked at:

  • Headroom and its cousin vision line height (VLH)*
  • Price and resell value
  • Consumer reports
  • Gas mileage (this is a commuter car for me)
  • Garage-fit

Weeding out the expensive, gas guzzlers and lemons, there were really just a few cars to seriously consider, although I did try on at least 20 vehicles from at least seven different dealerships. It was amusing to me to watch the reactions from the sales guys on the floor when I told them frankly but courteously that all I wanted to do was “try on a few cars.” They wanted to sell. I wanted to sit. Most of them were pretty cool about helping me out. The key piece of trying on each car was checking out my eye-line, sitting up straight and not leaned back to far, could I see out and up above (like stoplights) without slouching or bending? For some weird reason, in addition to low headroom, a lot of cars curve down from their peak over the driver’s head before the top of the windshield. Wasted space for tall people!

Here’s the spreadsheet I used: Vehicles for the Tall. Feel free to make a copy for your own needs and let me know if I missed anything. 

So in the end it was the Chevy Impala and its little sister the Malibu, and the Subaru Legacy. Of the three the Impala had the best visibility and legroom but I acted on a great deal I found on a Legacy because, in the end, I guess I really am a tightwad. But I’m happy with the purchase. I have the spreadsheet to remind me it was a good buy.

*Thanks to the folks over at Tall.Life for providing the initial research into tall-friendly vehicles. The reason that VLH is so important is because while a car may be tall (height top of roof to the ground), that doesn’t mean there’s a lot of headroom, and just because a car has a lot of headroom, that doesn’t mean that tall people will be able to see well out of the front windshield. VLH tries to give a metric for actual, usable vertical cabin room.

Statistically significant?

Business

If a p-value of 0.05 (5%) is too high, and the inventor of that threshold says it shouldn’t be used without consideration–which it is, all the time–then things we think are significant today just aren’t. We don’t always apply this kind of statistical rigor to decision making, but when we do we’re generally satisfied with this threshold. But we shouldn’t be.

Applied to product development teams, methodology matters a lot. But it can matter so much less than the talent of the individuals on a team. But methods and tools are still championed much more loudly than professional development.

In short, we should be looking for more obvious wins, and recognize that when something is close, but still statistically significant, it’s probably still too close to really move the needle.

 

With Regards to Suffering

Design

I read an article on Quartz by Karen Weese this morning that helped me reflect on society’s biases—as well as my own—around how people react with such a range of behaviors and whether that is primarily caused by the individuals themselves or their circumstances. In short, the idea is that when people behave differently than we would, it is not the individual that we should be skeptical of, but their context. I remain hopeful in mankind and I try to find opportunities to explain irrational behavior in terms that don’t condemn. Behavioral economics supports me in this and it drives us to better understand, and even predict behavior based on the things we can understand: context. Two applications from the article are noteworthy. In particular the second applies to my profession directly.

Poverty’s inherent lack of resources and time significantly but temporarily diminishes intelligence, making it hard for just about anyone to thrive. Skeptical? Read the article. Poverty is hard.

Job and situational stresses (particularly WWII bomber pilots) reduce mental bandwidth, which makes it hard to reliably execute even common tasks. In creating software for higher education classrooms, this means that we need to remember that our users aren’t focusing on us, the tool, but on their assignments. We can’t expect everyone to read and explore and emotionally invest in what we build because they’re already invested in other things. Know your place.

It’s too easy to write people off and explain away their failures or our differences on intelligence, race, political party or gender. Anyone can do that. If you want to talk about intelligence and diversity, invest actual time yourself in understanding where people are coming from and how little they may need to care about what you care about. As Dietrich Bonhoeffer said, “we must learn to regard people less in the light of what they do or omit to do, and more in the light of what they suffer.”

Loving Your Fate

Uncategorized

I was reminded this morning of the tragic burning of Edison’s labs and his aloof response, “Go get your mother and all her friends. They’ll never see a fire like this again … We’ve just got rid of a lot of rubbish.” I’d heard the story before but what I didn’t know was that Thomas carried a coin carrying the latin phrase “amor fati” or love of fate. Clearly he had learned to embrace the machinations of the world that were outside of his control. Completely independent, I was struck yesterday by the haunting duet Come What May from the movie Moulin Rouge. From the lyrical word choice alone, it is clear that these two lovers face their fate daunted but determined.

There are so many things that we cannot control, and perhaps the greater portion of those we sometimes believe that we can. I am reminded today that not only should I NOT waste effort, but recede and embrace the reality that is happening before me. Although driven for greater realms, embrace the present, there is so much to do here.

Keeping your port clean

Uncategorized

Now don’t be grossed out, but this is part of what I found in my iPhone 6 lightening port last night. My charging cord wasn’t fitting securely and I was worried that I might have a loose connection in the phone. After confirming a suspicion with a flashlight that lint-crap was causing the connection problem, I fished this out with some tweezers. It’s not a lot, but enough to keep it from charging.

 

 

 

Keep your ports clean.

Investing in professional development

Business, Technology

There’s some debate still about these 20x developers out there, complete geniuses that gave rise to the “rock-star” moniker that every company seemed to advertise for. I’ve remained a touch skeptical–not that there aren’t amazing software engineers, I know several — but I’m skeptical because we still don’t have a really good, accessible ways to measure human contribution to software. Lines of code, commits and story point velocity are readily available. Regressions, debugging and runtime numbers can be gathered as well, but we know that all this still doesn’t paint the whole picture. Also add in the real-world impact that other factors outside of development have on performance as well: good product management, architecture and QA among them, but also deadlines, poor communication and bad management. With all of these variables, it’s going to be pretty tough to accurate gauge order-of-magnitude differences between programmers in the real world. And frankly, I don’t know that you need to because in your gut you already know.

“The differences arising from individuals in any given study will drown out any differences you might want to attribute to a change in methodology.” — Steve McConnell

Back in 2011 Steve McConnell responded to criticisms of his 10x programmer claim thoughtfully by pointing out what he was seeing in the studies that have already been done, most not even focused on individual contribution. What he found was that “the differences arising from individuals in any given study will drown out any differences you might want to attribute to a change in methodology.” In short, it nearly totally depends on who’s on your team. However, over-emphasis on this leads to ignoring methodology and tooling altogether and focusing instead on individual development and hiring, which would be short-sighted. My point here is that on the balance, the latter should constitute a more significant portion of team building efforts.

The trouble arises when you commoditize development. While there are many software tasks that require no planning or design, there is much more that requires careful thought. As Yevgeniy Brikman said in support of the 10x developer, “It’s not about writing more code; it’s about writing the right code. You become a 10x programmer not by doing an order of magnitude more work, but by making better decisions an order of magnitude more often.”

“It’s not about writing more code; it’s about writing the right code. You become a 10x programmer not by doing an order of magnitude more work, but by making better decisions an order of magnitude more often.” — Yevgeniy Brikman

This is why I prefer the title software engineer. Writing good applications is really about a mind well-suited for building: choices, compromises and the collective wisdom of personal experience and industry best practices. Don’t commoditize development. It’s a highly-talented and highly-compensated profession. It’s not about nuturing a team, it’s about providing the humans working around you with the best possible resources to be successful, innovative and frankly, fun to be around. Yes, tools matter, and methodology matters–they matter a lot and they can have a big impact on the quality and speed of your work, but investing in these while sacrificing investment in the professional development of the individuals on the team… well… that’s as bad as it sounds.