Core principles: your compass in the storm

by Seth Petry-Johnson 30. April 2013 04:33

Software development can be chaotic. We often need to make decisions based on missing data (or data we know is likely wrong), and it's difficult to ask outsiders for advice because the "right" answer is often context-dependent. In essence, successful software development depends on repeatedly selecting the least bad option from a set of imperfect solutions.

In practice, this means that developers cannot simply memorize solution patterns or "recipes". If I say "authentication" and you immediately think Forms Auth, then you're short-circuiting the selection process without evaluating the options. Same thing if I say "shorter feedback" and you immediately think "two week sprints". You can't make a good decision without evaluating your options, and just because you choose Solution A on a similar problem a month ago doesn't make it the appropriate solution to today's problem.

"Been there, done that" is not a decision making process! 

Making decisions is hard. The deeper you analyze a problem the more variables you identify, and the more variables you identify the harder it is to reason through the myriad ways they interact. It's so much easier to look at a problem, wait a few nanoseconds while the pattern matching functions of your subconscious mind do their magic, and then do the same thing that you did the last time you had a similar problem. After all, you tell yourself, it's the "pragmatic thing to do" because you don't have to "waste time" on analysis or research. "The devil you know", and all that.

Not so fast.

Pattern matching is a great heuristic for quickly identifying potential courses of action, but not for selecting the best one. Making the best possible decision requires greater attention to detail and greater appreciation of nuance. If you get the details wrong then it might seem like a good decision at a high level, but eventually you'll suffer death by a thousand papercuts. [Or you'll go broke under technical debt, etc. Insert your favorite metaphor here]

So how do we select from that set of imperfect solutions?

The key to making good decisions is to articulate your core values and principles, and then use them to derive a solution. Rather than memorizing specific solutions, memorize the steps you follow and the questions you ask to arrive at a solution.

For example, at Heuristic Solutions we have identified four core values that guide everything we do:

  • Understanding: we can't be successful unless we know what "success" looks like
  • Predictability: surprises are disruptive; we value procedures that minimize their impact
  • Productivity: success requires efficient operations
  • Quality: we value doing it right the first time; re-work is anathema to us

When making a decision, we frame it in context of these values to better see the trade-offs at play. For example, a low degree of Understanding means we can't be very Predictable, so we do more up-front analysis when predictability is crucial. When Productivity is necessary then we invest in Quality so that we can preserve velocity over time. 

This process forces us to consider those pesky (yet all-important) details specific to each situation. Sometimes this leads us to take radically different approaches to similar problems, but in each case we know we're maximizing for the things that truly matter to our success.

What are your core values?

What matters most to your organization? If you haven't already articulated your core values, take a minute to do so. Do you care about speed to market? What are you prepared (or not prepared) to sacrifice to get it? What does "quality" mean to you? How important are estimates to your planning process or stakeholders? Is it more important to maximize developer productivity, or team productivity?

When you're done, write them on your team board. Repeat them out loud each time you make a decision. Have discussions about which values are more important in each scenario, and then brainstorm ways to maximize those specific values. 

One parting word of advice: don't be afraid to follow your values, even if they contradict "best practices". While it's never a good idea to blindly ignore prevailing wisdom, realize that only YOU can fully appreciate the nuances of your specific situation. Core values are your compass, and by trusting them you allow yourself to select the best possible solution for this specific decision, ignoring "one size fits all" advice that might otherwise get in your way.

(Of course, if you frequently find yourself ignoring best practices then you might be thinking your situation is more unique than it really is. More on that in a later post!)

Bottom line: articulate what really matters to you, and then consciously and intentionally use those values every time you make a significant decision. You might be surprised at where this process takes you.

Avoid heroics; real value comes from discipline

by Seth Petry-Johnson 1. August 2012 19:11

Spend any amount of time in this industry and you'll eventually end up playing the hero. Maybe you meet that deadline by pulling a 70-hour week, or you fix that production issue by editing a script or database procedure directly on the server. You shipped the product, you fixed the bug, you "got the job done". You're a hero, right?

The only problem is, heroic behavior is dangerous. I've played the hero enough times to know what happens after the dust settles:

  • You pull a 70-hour week and hit the deadline, but the code sucks. It isn't tested, it has bugs, or it just feels like a half-assed feature. 
  • You hot-fix a file on the web server, but forget to update source control. The next deployment replaces your fix and re-introduces the bug.
  • You hot-fix the database server, and the next deployment crashes because a table or column already exists.
  • You burn out, lose focus, and make stupid mistakes.
The common pattern here is that you've achieved a short-term goal at the cost of highly unpredictable future results. Someone, somewhere, will have to clean up the mess when it catches them by surprise. 

In other words, you've created bad technical debt that is unintentional, hard to manage, and hard to quantify.

So what's the solution? 

It's certainly easier said than done, but the solution is to stay disciplined and stick to your process

If that process says you write tests first and get QA feedback before committing to trunk, then that's what you need to do... even if it means missing a deadline.

If that process says you must create a formal release package to modify the production database, then that's what you do... even if it means taking longer to fix the bug.

Discipline yields predictability by forcing you to be proactive. It helps minimize future surprises and prevents you from becoming overly reactive, which can often lead to a cascading series of errors when you start jumping from fire to fire.

When to cheat

There are obviously exceptions. If the server is totally down, and you know of a quick fix to bring it back online, then maybe you should fix it. But if you've internalized these principles then you'll feel real damn uncomfortable doing it, and that discomfort will remind you to take the necessary "after-action" steps to pay back that technical debt immediately after the crisis passes.

Remember kids: avoid heroics. Real, lasting value comes from staying disciplined... especially when you feel pressure not to. 

A Good Consultant Is Always Selling

by Seth Petry-Johnson 16. May 2012 19:24

When I was just starting out as a consultant, a friend and co-worker commented that "a good consultant is always selling". Three and a half years later I've come to agree, and in fact I think an appreciation of this concept is critical to becoming a truly effective consultant.

In consulting, like many industries, attracting new business is time consuming and sometimes expensive. It's hard to stay fully utilized during project transitions and gaps in the work schedule can quickly eat away at your profit margin. Good consultants understand that adopting a sales mindset allows them to convert existing engagements into larger ones, and one-time customers into repeat clients.

Done right, this is a service to the customer, not a sleazy "sales technique" to increase billed hours. I'm not talking about artificially inflating schedules or gold-plating unnecessary features, but rather caring enough about the customer's end goals that you can help them identify opportunities they might otherwise miss.

To set the stage, a quick example

My team recently spent a week making changes to an existing feature for a customer. During the iteration demo, I realized that the changes we'd made were going to interact awkwardly with a feature coming in the next iteration. Though it was implemented "per the spec", the combination of the two features was going to be confusing and hard to use.

At the same time, I realized that by re-designing an existing feature of the site we could not only improve that feature, but also improve the feature we'd just built and completely avoid the need for the upcoming changes that were going to be so difficult. In short, by totally re-envisioning a section of the site we could radically simplify some key functionality.

This re-design was totally out of scope for the project goals and would cost the customer at least a week of additional work, but they were thrilled to add it to the backlog anyway! 

Why? Because I had found an idea that was worth more to them than the cash they would trade for it. I had successfully "sold" them a concept for improving their software. 

To sell successfully, you must understand what your customer values

I'd been working with this customer long enough to know what they consider "valuable". In this example, I knew that they cared deeply about their public UI and that the improvements I suggested would significantly simplify it. Making suggestions that are aligned with your customer's values increases your chances of success and avoids coming across as "that guy who is always trying to sell us work we don't need".

Conversely, I know that they have very different values regarding their administrative interfaces. Suggestions to spend money simplifying the admin UI would likely fall on deaf ears; they generally favor more powerful and complex admin features that allow their staff to be more productive.

Key point: spend time understanding why your customers value the features they build. The deeper your understanding of their business model, the personas of their users, and their core strategic values, the better the chance you'll have of spotting sales opportunities. It doesn't feel like "selling" when you're aligned with your customer's needs.

To sell successfully, you must be creative

"Selling" in this context means coming up with new and valuable ideas on your own. I find that thinking about my software from the user's (or customer's) perspective often yields valuable results.

In the example above, I was trying to determine how an end user would use a new feature in combination with an existing one, rather than testing it in isolation. Once I put myself in the user's shoes I immediately noticed some issues that the entire team had overlooked, and once I had identified the problem the creative juices kicked in and the solution became very clear.

It also helps to practice wearing your analyst hat. Don't assume that just because the client asks for a specific interface that they considered other (better) options. Clients, especially non-technical ones, lack your sophisticated understanding of software systems. They may have ruled out the best solution because it seemed "too hard", when in fact it might be totally doable. 

Key points: innovation comes from creativity, and creativity comes from considering different viewpoints. Try "thinking like a user" to identify sales opportunities, and look at requirements from multiple angles. Practice those BA skills!

To sell successfully, you must have a "customer service" mindset

Let's be clear: I'm not talking about extending contracts to "milk" a budget or convincing customers they need something they don't. There's a big difference between being motivated to serve the client and being motivated to increase billing revenues; in my experience, if you focus on the customer service the revenue will follow.

In fact, being motivated by customer service sometimes means you will identify a less expensive solution then the client asked for and/or approved. Don't be afraid to share those cost-saving ideas! In many cases the customer will just swap in additional "nice-to-haves" rather than reduce the budget, but even if they do reduce the budget you've demonstrated integrity and built trust. More often than not, that customer will come back.

Key point: truly care about the customer. Focus on what's good for them, and you'll benefit as well.

In conclusion: always be selling offering

Perhaps a better way to think of this is that "a good consultant is always offering additional value". Done right there's really no selling involved; show your customers ideas that are clearly aligned with their values and worth the development cost and they will often do the rest.

And if they say no, that's cool. Offer something else of value. As long as you're properly motivated you'll find most customers are grateful for the suggestions and come back to you for additional work many times over.


Seth Petry-Johnson

I'm a software architect and consultant for Heuristic Solutions.

I value clean code, malleable designs, short feedback cycles, usable interfaces and balance in all things.

I am a Pisces.

Month List