How to develop Micro-ISV software.

If you’re going to successfully fire up your micro-ISV, you need to fire your old ideas about software development, be they UML, RUP, agile, SCRUM, extreme or none: they fit like shoes on fish.

Every single methodology for developing software I’ve heard of in over 20 years in this business assumes you’re part of some vast team of programmers, never a programmer working alone. What’s more, each and every existing software development process assumes someone is going to hand you a nice gift-wrapped definition of the problem you’re going to solve via code. That is exactly what won’t happen when it comes to developing a micro-ISV app or web site.

Today’s software design theories are like using a power drill as an ear cleaner - they can be used, but it’s not a good idea. We need a better approach, one based in the reality of one or maybe two programmers who must also define the problem and its solution and who want to do so before their savings run out.

Don’t underestimate just how hard defining the problem domain is, or just how difficult it is to nail down in the absence of actual customers who will tell you what they want. Unless you plan to take a few years unpaid leave from your life to do intensive market research, endless focus groups and surveys, at best you are only going to have a very approximate idea of who is going to be using your software how to solve exactly which problem in what precise way at least all the way through to your public beta.

Now add to that reality this consideration: if you don’t write software that has an extremely low public bug count, there is no way in hell you’re going to succeed as a micro-ISV. There’s nowhere to run and nowhere to hide in a micro-ISV when bugs start to surface. At best, more time than you can afford will be spent doing tech support and bug fixes; at worse, you sales will plummet, your customers will bolt and you’ll be back begging for your old corporate job, bitter and hurt.

Because of these facts of micro-ISV life, your micro-ISV software development process must orbit around two objectives above all else: the need to better serve your market as you define it and the need to have as few bugs as humanly possible in your code.

Micro Extreme Waterfall Software Development

So here’s the first part of what I call MEWS – Micro Extreme Waterfall Software development. This first post is all about what other methodologies call requirements gathering, story telling, rapid prototyping, sitting down with customers: the requirements Ying as opposed to the coding Yang.

There’s no lofty theoretical underpinnings, no studies of 1,254 organizations, no conferences to back up MEWS. Instead, I’ve tried to swipe the good and relevant parts of various methodologies that logic and experience tell me will keep me in a stable orbit around my two objectives as I gear up for my next micro-ISV product. I hope they will help you fill in the blank between the product you can see in your mind’s eye and getting down to the nuts and bolts of architecting and coding your app.

MEWS: Defining your software.

  1. Profile your Customers. Your first step absolutely needs to be profiling exactly who out of 6 billion plus people will use your software. Pursue them online, track them down and interview them offline, write them up in as much detail as you can muster. Are they in their 20s or their 60s? Are they locked in a corporate IT system or at home? Are they spending 4 hours a day with your app or 10 minutes a week? These and 50 other questions need answering.

    Your customers’ attributes, attitudes, needs, wants and expectations are the canvas you are going to be painting on - you need to know what they are as your very first step in your software development process. They are going to decide for you whether you’re building a web app, a desktop app, and all the other technical decisions you need to make before going forward.

  2. Start with the Interface. Your customers could care less whether you’ve got a loosely coupled, highly coherent MVC class structure or little furry digital hamsters eating spaghetti code behind the interface they see. They will give that interface 10 seconds at most before deciding it’s worth any more of their time or moving on.

    This painful reality means forget about UML, RUP etc. and get the interface right by making it - not the plumbing - the center of your software design process. If your interface doesn’t fit your customers, if they in their strange unprogrammer-like way don’t get it, not all the polymorphic overloaded classes in the world are going to get their money into your pocket.

    How you design and iterate your interface is up to you: I like paper prototyping, others have had good success with various products. Whatever works, and lets you iterate with the least overhead is good.

  3. Write little and big stories with happy endings. You need to go through and write up both exactly how your customer will interact with your software interface and what your Customer will be able to accomplish with your product. They are not the same thing.

    A little story for example might be how will your Customers be able to find an invoice in your accounting app? That’s one or more little stories, somewhat similar to how UML use cases nail down what the user clicks and enters and what the app then does, but without all the formalism and baggage. They each need a happy ending: the customer gets what they expected to get out of the software at a given point.

    On the other hand, you have big stories, like how the Customer can save 30% of their fuel costs by using your route-planning software. These are the stories sell your software, and they need happy endings too. They also need to be documented so you can see exactly how your software will make these stories real.

  4. Document your decisions. You are going to do and redo defining your customers, interface and how the two interact a lot. As you do, you are going to be making decisions about what your app does and how it does it. Document your decisions, be it in Word, an outliner or a wiki. At a bare minimum, you want to record each technical and interface decision and the primary reason for that decision.
  5. That’s the core of the designing side of MEWS; but no methodology is worth its salt without a couple of other things thrown in at the end:

  6. Less is more revenue. Remember those 10 seconds a customer looks at your product before breaking your heart? What features overwhelmed them? What was not instantly, blindingly clear at a glance about your app and why they absolutely had to buy it now?

    Cut the complexity, lose the cool Ajax tricks that look like tricks, dial back the number of things in front of the user at any one time. Simplify before you code, not after.

  7. You are a programmer, you are not normal. Specifically, your experience with software is not the norm. Why, doesn’t everybody understand how to pin a docked window? No, they don’t: they are still trying to figure out what command in word fixes the sentence they just typed in capital letters.

    Your software has to work within the Customer’s context, not yours. So unless you are writing software for programmers, or sysadmins, or the like, dumb it down. Don’t be rude or patronizing, just hide the complexity you spent days and weeks learning but your Customers did not and will not.

I’m sure MEWS is not perfect – software development methodologies never are. But hopefully MEWS will give you a starting point to develop a set of practices that work for you. Next time, I’ll don my flameproof suit and cover the actual coding part of MEWS.

Why "Waterfall?"

Aside from the fact that waterfall methodologies are Evil, it doesn't sound to me like you've really described one! All of your advice is good, and I think it could (and should) be stated as an iterative approach -- design your interface first, but don't try to design every last detail of your entire future system in one sitting. Tell just enough stories to describe something useful, flesh out the UI, build something, test it, get feedback from real people, then move on to some new stories and repeat until you have a real Product.

I definitely agree with the premise of skipping the typical corporate design approach (although with one nit -- use cases are always useful as an extremely fast, lightweight method for modeling the problem domain -- not sure what "baggage" they have?). Thanks for the article!

Brian Moeskau
MyHomePoint.com - Powering the Modern Family

Why waterfall indeed!

1. As nice as agile is, you do need some advance planning to move from phase to phase. If you do not, you will linger in planning limbo.
2. I needed a W word to make a nice acronym! :)

Agile != Lack of Planning

Common misconception, but Agile does not mean lack of planning. More than anything, it is day to day planning to provide something of value asap.

Most Agile methods call for iterations to last 2-4 weeks and then adjust plans, etc before continuing. The entire concept of "Release Early, Release Often" comes from this direction.

If you do a classical waterfall without any customer feedback/interaction until the end, you a) don't provide any value until then and b) are in trouble if any assumptions/requirements were incorrect.

Couldn't have said it better

Couldn't have said it better Keith ;)

Also, notice I did not even say "Agile" with the capital A -- I just said "iterative" (as opposed to top-down/waterfall). Like Keith said, the key is creating a process in which you constantly loop back around through the develop-test-deliver cycle, irrespective of how long it takes or what methodology (if any) you choose!

Thanks for the article Bob -- I do think it's a topic that merits more discussion than it often gets within the mISV circles.

Brian Moeskau
MyHomePoint.com - Powering the Modern Family