Development Team Best Practices

speedometer

I wanted to put together some thoughts on high level best practices for your dev shop.  These practices will skew towards larger dev shops inside of big corporations but can also be applied to 1-2 man teams.  These thoughts are inspired by a combination of The Pragmatic Programmer and The Joel Test.  I read both of these sources early in my career and they have continuously provided inspiration on what kinds of practices highly effective dev team should follow.  Futhermore I’ve found it surprising how many shops I’ve worked with that break these practices.  Following these practices will increase your dev team’s effectiveness, making for happy developers and manager.  Breaking these practices will result in a slower development velocity and frustrated developers and managers.

  • Streamline your local build process.  

Do you think your build process is pretty fast?  It could be faster.  If it takes more than a few seconds to redeploy your code you lose your train of thought – and there is a cost to putting that train back on the rails.  As someone who has spent a lot of time doing Enterprise Java development, it often amazes me what developers will put up with in their build processes.   Here are a couple of tips to decrease build time:

    • Your environment probably supports some sort of hot swap method where you don’t need to do a full build after every change.  Java’s JVM Hot Swap feature allows this for some cases.  I’ve also heard very good things about JRebel.
    • If you have a medium to large sized application, you probably don’t need to rebuild the whole thing all of the time.  Make sure you’re not rebuilding more components than necessary.  Here are some kinds of things I’ve seen automatically included in a full build that could be excluded from a “fast” version of your build: code generated from wsdl/xsd, database migrations, unit test suite execution, minification/obsfucation of js/css.  In Java, the war/ear step will package all of your files into a war/ear.  When you deploy that war/ear to your application server it will unpackage all of the files.  You can eliminate a step by just copying your war/ear directory directly into your application server.
  • Use a debugger.  

Do you test your application by inserting new log statements and redeploying?  Stop it!  One of the best ways to cut down on redeploy time is to not have to redeploy.  Every single commercially used language supports debugging.  Here are a few links to get you started using a debugger with your language

  • Automate your QA builds and minimize QA downtime

Your QA build process should be quick and painless.  I would shoot for a combination of automated QA builds (2 or more times per day) and one-click, on-demand deployments.  The outage to a QA environment needs to be small – 5 minutes or less – to keep the deployments painless enough to not disrupt the workflow of the QA staff.

Doing frequent, automatic QA builds does a couple of great things for your IT organization- it sets a precedent that your team has the ability to quickly turn around fixes.  It also minimizes the impact of bugs in your QA process;  After all, if your team finds a bug, it’s not a huge deal since the bug might be resolved in a few hours.

Contrast this approach with an organization I recently worked with that only did two QA builds per week because their build process took so painfully long to complete.  Every bug became a news headline.  The management team would often choose not to fix bugs because of the huge turnaround time and the risk of additional lost time in case a bug fix was not successful.

  • Treat database schema updates like source control

 SQL is code, and your database structure is the product of that code.  In the same way that every developer working on a project needs to be able to run the software on their local system, those developers also need to be able to run their own copies of the database.  Database changes should be part of your normal build process, and like your code, your database schema needs a version so you know which changes have been applied.  This helps keep your development, test, and production environments all in a sane state.

It’s easy to fall into the trap where a database is very difficult to create so you end up running one development database for all of your developers to share.  The problem comes when you need to support multiple work streams at the same time – this means you need to simultaneously run multiple versions of the schema at the same time.  You can work around this problem by adding more schemas and more hardware, but the overhead involved may make it really difficult for developers to do the kind of risk taking and rapid iteration required to reach a high velocity.

I recommend using flyway or liquibase to manage database changes for most technology stacks.  Rails has built in support with Active Record Migrations.

 That’s all for now.  Please send feedback in the comments if this post has helped provide value for your team, or even if it seems too rudimentary.  I’d be happy to do a deeper dive on any one of these topics if there is interest.

How to Teach Your Old Business New Tricks – Lean Startup Style

You have an established business built around a mature product.  Customers are buying, revenue is being generated, and presumably there are multiple people making a comfortable living to ensure that things stay that way.   Inevitably what follows is a culture of devotion to the status quo, or perhaps to marginal improvements (like process improvement and cost reduction). The organization becomes extremely risk averse. While the market around your business never stops changing, your slow-moving company can either adapt or die.

One day an innovator in the organization identifies a new business opportunity and approaches you with it.

Hey, there’s a new market we could capture. It’s big. We just need to take a little risk to get to it.

Senior Management may say “We’re not in the business of taking new risks. We’re in the business of selling what we have.” And we can’t blame senior management for this response. It’s political – and the stakes are huge. If a senior executive gets behind a new risky initiative and it fails, they are fired, or at least their career takes a big hit. Even if there were a large reward potential the risk may not be worth it to the executive.

What if we optimized this problem and reduce the risk by limiting the potential downsides?  Let’s start by identifying the major risks:

  • Brand Risk.  What if you release your new product and it is a total failure?  Your company’s name will be forever tarnished, and sales of existing product will get hurt as a result.
  • Financial Risk (both capital and opportunity costs).  To avoid Brand Risk we should put extra effort into making sure that the product is fully polished and ready for prime time.  We will need teams of people working for multiple months (or even years) on the product development.
  • Personal/Political Risk.  If I’ve championed this project and it turns out to be a flop, I will suffer public embarrassment and will likely get fired/asked to resign.  Hmm, maybe instead I should play it safe and let someone else take that risk if they want to.

Tarnishing your brand, losing money, and getting fired.  Yep, those are giant risks.  What if I told you that you could reduce each of these risks to manageable amounts?  Within a small pocket of your company you can create a culture of innovation.  Within this pocket you must encourage experimentation and celebrate failure in the interest of learning.  Treat pocket of innovation like a small startup inside your larger organization.

We can solve this problem together.  To get started building our new innovation culture we must first accept the fact that we will NOT get the product right on the first try.  In fact, you have no idea how many iterations you need to make to get it right.

Failing often is OK as long as we limit the scope of our failures.  We are not talking about orders failing to emerge after a lengthy product development cycle and advertising campaign.  We’re talking about showing a customer a drawing of the product and hearing that it doesn’t quite do what they need.  By limiting the scope of our failures we can decrease the duration of these business model experiments and increase their frequency.  Under these conditions innovation is free to thrive.

How liberating!  The first try is not what matters – what matters is that you iterate over your business model until you get it right, ultimately achieving Product-Market Fit (hopefully before your competitors and definitely before you run out of money).   The other key is to limit spending until you’ve achieved product-market fit – for example, don’t spend money on advertising until you’re confident that the product is viable.

Once the organization accepts this idea it can start making rational choices to minimize the risk associated with the new business opportunity.  Let’s look at each of our major risks and see out how to minimize them given these new assumptions about our uncertainty in achieving product-market fit.

  • Brand Risk is non-existent.  If you build a product that nobody wants (and you haven’t advertised it yet), then nobody even cares!  Just resist the urge to create ‘buzz’ around your product launch until you’re pretty sure you’ve gotten it right.  You can’t fail to meet expectations if you don’t create any.  To further protect the original brand, you could release your new product under a different brand, and only attach the parent brand when you’ve proven the success of the new product.
  • Financial Risk – limit spending until achieving Product-Market Fit.  The solution to mitigating financial risk is the Minimum Viable Product.  The basic idea is to build only what is absolutely necessary in order to validate your assumptions about your business model.  If we disprove an assumption, we come up with new assumptions and modify the MVP accordingly in order to validate the new assumptions.  Then repeat.  Eric Ries calls this the Build-Measure-Learn cycle, and it is the basis for the Lean Startup movement (fig A)We spend as little money as possible on the MVP, and we don’t spend money on advertising activities until we’ve proven product-market fit.  Sometimes this means building a single landing page to see how many people click on the ‘sign up’ button.  Sometimes it means building a non-functioning prototype and taking it to a few customers to get their feedback.  Still, even if we’ve only got a couple of people working to iterate on the MVP, money is being spent, and it can be tough to quantify progress to senior management.  The bottom line is that it doesn’t take that many resources to prove whether or not a business idea is viable (and if the idea is not viable you should kill the project).
  • Personal/Political Risk can minimized.  We’ve minimized brand risk and financial risk, so the political risk for the project champion is also minimized.  Under these conditions, senior management should be able to reassure the project champion that her career is safe even if this business experiment does not achieve Product-Market Fit.  This gives the project champion the confidence she needs to run without constantly having to watch her back.

The result is a framework for creating innovations in your company, ensuring that it will always be able to move with the market and capitalize on new opportunities.

 

This article was inspired by the works of Eric Ries’s book,  The Lean Startup and Steve Blank’s Customer Development Methodology.  For pragmatic advice on implementing the Customer Development Methodology, check out Mike Fishbein’s article on Customer Development Questions.