What you need to sell software

You have a great idea for a new application, platform, website or device. All you have to do is write the software, and you’re in business, right? Nope, sorry, there’s a lot more you have to do if you want to be in business, and yet more to stay in business beyond the first release.

The following is an attempt to distill down what I’ve learned over the years about the business of making software. Most of this comes from my ten years at Juniper Networks working on the team responsible for managing source control, bug tracking, release planning and build & release for the industry-leading Junos™ Network Operating System. Right now it’s a sketchy outline, because it’s a very complex subject.

I would be pleased to help your company get started on the path to reliable and repeatable software releases. I can help draft policies and procedures, advise you on what software packages would work for you, install and configure those packages, and train your developers to use them. Contact me and learn more.

• Repeatability
  • You don’t build the software just once
  • Development environment
    • Same for everyone, or free form?
      • Some developers are quasi religious about this
    • Multiple platforms?
    • Use an IDE?
      • Very valuable for navigating a large codebase
      • Can add overhead
  • Source code control
    • Keeping track of changes in the codebase
    • Many to choose from
      • Distributed or centralized?
      • Free or proprietary?
    • Every developer needs to use it
    • Need to decide on policies and procedures
      • Branching model
      • Code review
        • Pre or post commit?
        • How formal?
        • Use a tool to help organize it?
      • Number of repositories
  • Build and package
    • Turn source code into something that you can hand to a customer
    • Build
      • Compiler
        • What version?
        • What platform do you build on?
        • Need to track this per release
      • Process
        • Makefile(s)
        • Scripts
        • Written procedures (less than ideal)
    • Package
      • A single file that can be passed to the customer / rollout team
        • Format
          • tarball, zip, rar, etc?
        • Multiple platforms?
      • A way for the customer to turn that file into a runnable install
  • Testing
    • If you don’t have at least the sanity test automated, you’re doomed
  • Release
    • Getting the software from your dev/build environment to the customer
    • Labeling
    • Announcement of availability to customers
    • Packaged software
      • Download links or other distribution method
      • Access to old releases
    • Network/web service
      • Rollout plan
      • As automated as possible
        • Repeatability is critical
        • People are usually tired and cranky
      • You must have a rollback plan
        • Rollouts have a way of going wrong
        • You may discover a horrible bug
• Records
  • Bug tracking
    • You need a list of everything that’s wrong with your software and process
      • Bugs arrive in bunches, and are fixed slowly over time
      • You can’t afford to lose track of them
    • Internally discovered
      • You need to file bugs as you find them during development
      • And during testing
      • You will find more bugs than your customers
        • Or pretty soon you won’t have customers
    • Customer bugs
      • Once you’ve got multiple customers, you need to filter this source
      • They should be able to search the bug db
        • But you probably don’t want to let them see *all* the bugs…
    • Needs to be integrated with source control system
      • When/where did we fix this bug?
      • Why did it come back?
      • What bugs were fixed in this release?
      • What release do I have to install to avoid this bug?
  • Documentation
    • You need to document policies and procedures
  • Feature and release planning
    • Everyone wants to see the future
    • Developers want to know what to work on and when
    • Customers want features and bugfixes
    • Marketing & sales want to know what they can promise
    • Predictability is very important here
      • A regular release schedule
      • Features and bugfixes arrive when promised
  • Archiving of old releases and code
• Disaster Recovery
  • Surviving fire flood, earthquake and the loss of your top developer
  • Physical disasters

    • Think about the level of disaster you’re going to prepare for

      • Multiple disk failure on a critical server
      • Accidental sprinkler discharge in the server room
      • Your whole building burns down
      • Magnitude 8 earthquake
      • Global thermonuclear war
      • At some point, you’re going to throw in the towel
      • Plan appropriately

      First off, backups, including offsite backups

      • You have to actually test your backups
      • Try to restore from an offsite backup
      • Find out if it works before it’s too late

      If you’re planning on surviving fire, flood or the like, plan on having a minimal environment at first

      Consider setting up a minimal environment somewhere offsite before you need it

      • Test it regularly
  • Personnel losses
    • If you think you’ll have to close up shop if So And So leaves the company, you’ve got a problem
      • What if Jane gets hit by a bus?
      • You need “Bus insurance”
    • Documentation
    • Commented code
    • Get them to train someone else
    • Anything you do for this will be useful when you hire another developer
• The Software Itself
  • Software has internal structure
  • Needs to provide stability for its data
    • Backup files for critical data
    • Recovery of configuration