Say no to low-value features

In most code bases, you can get 80% of the business value with 20% of the features. Imagine if the time spent on the other 80% of features had been spent on high value features - you'd have four times the business value! This is what Google realized in 2011: they needed more wood behind fewer arrows. I have great respect for Google's willingness to kill products that aren't going to have major impact. So many organizations have struggling features that get blindly maintained and never get killed. This is a tragic mistake and a massive tax on the organization.

Engineers are the gatekeepers

"The difference between successful people and really successful people is that really successful people say no to almost everything" - Warren Buffett
If engineers are the ones implementing tasks, then they are also the gatekeepers of which tasks get done and in what order. However in many organizations, the prioritization process is done with minimal engineering involvement. Sometimes this is thought to save engineering time. Prioritization that excludes engineers wastes far more engineering time than it saves. Engineers should be given business objectives to meet and should be a critical part of the prioritization process to hit those objectives. Engineers must be protective of their own time by saying no to work that does not align with their goals. Any work that is worth doing will have a clear argument for how it contributes to a business objective, otherwise the business objectives need tweaking.

Measure feature value aggressively

You should have a constant pulse on the value of every feature you maintain. One metric is: what would the business lose if this feature were unavailable for 1 hour? Effort spent on a feature's automated tests, maintenance, and risk-avoidance during changes should all be proportional to its business value.

Nearly dead code is much worse than dead code

Nearly dead code must be maintained and is much harder to remove than dead code. Low-value features are nearly dead code - just waiting to be deprecated. It's not always obvious which features are low-value unless you measure their value from the start. Avoiding adding low-value features is much easier than removing them; removing them is much easier than maintaining them. When you do add a feature, release the simplest possible version in a small roll out. Measure its value against a business objective, and be ready to retract it quickly if it doesn't deliver value.

Actively seek out low-value features and remove them

All code has a carrying cost. Any time I am refactoring or maintaining code, I am looking at the code in the same area for features that might not be worth keeping. If I don't understand the business value behind something, I search until I can find one, and often propose removing the feature if it no longer seems worth its carrying cost. This exercise has the added value of increasing engineers' understanding of the code they are maintaining.

Comments

Post a Comment

Popular posts from this blog

Crossing the Rubycon

I first learned Ruby about a year ago and it quickly became my scripting language of choice; a position I doubt it will ever lose, hence the name of this blog post. Here are some of the reasons that I prefer Ruby over Python, NodeJS, and PHP, for most use cases. Testing The primary reason I prefer Ruby is how great writing tests is. Tests in ruby can be incredibly concise and natural. The built in mocking, stubbing, and monkey-patching functionality is very powerful. I particularly love the way contexts can be built up with let(:...) to have very descriptive and concise tests. The philosophy If you look at a language like PHP, it has basically no philosophy behind it, at least not a consistent one. Hence you end up with all sorts of weird behaviors. For example, consider preg_match , which finds matches of a Regex in a string: preg_match() returns 1 if the pattern matches given subject, 0 if it does not, or false on failure. Gross .  Wait, where are the results of the regex match? // 
Read more

The many benefits of working in small increments

If you're a software engineer, you've likely heard of the Single Responsibility Principle  (SRP). I believe it's the single most important principle in software engineering. The simple explanation is that one object should do only one thing and do it well. Having a well defined single responsibility makes code easier to understand, change, delete, and test. The complexity of code grows exponentially with size. Two 100 line classes, with proper segregation of responsibility, are significantly easier to understand than a single 200 line one. SRP is the "work in small increments" principle for code, and the same exponential growth in complexity applies to much more than just code. Working in small increments shortens the feedback cycle, which is the best thing any organization can do to increase its velocity. Small Tasks Every task should be small - small enough to complete in less than two weeks, ideally less than two days. Small tasks are easier to write, understan
Read more

The two qualities of great software architecture

Great software architecture solves a present business need and is easy to change when business needs change. Software architects have developed a number of heuristics: patterns and principles that help to achieve these goals. A software engineer that applies but does not fully understand these heuristics may implement them in situations that run counter to the goal. To write great software, it's important to understand how each pattern and principle contributes to the goal. Entire books have been written on most of these subjects. This is intended to be a brief overview, not an exhaustive list or explanation.  Solving a present business need Most users could look at an application and tell you whether it solves a present business need, aside from some of the more subtle nuances. For example, an application may solve one need but is not secure, which is usually one of the business requirements. Some of the criteria that may roll up to this metric, depending on your business: User ex
Read more