Assess – Decide – Do for Programming

Assess – Decide – Do is a simple life management framework. Despite its somehow pompous acronym, ADD is overwhelmingly simple, so simple that you may even overlook it. Every ADD cycle is based only on 3 fundamental activities: assess, decide and do. And since we’re going to talk about ADD and programming, we can borrow a little bit the object oriented paradigm: ADD is an abstract class, and every implementation you instantiate will be a subclass of it. It’s entirely up to you to create your very own ADD implementation in whatever area you want to improve. For instance, I already wrote about ADD for relationships, and will write about several more topics soon.

In today’s post I’ll sketch some outlines on how ADD can be used for software development. I do not claim to give you something complete, nor even formalized, but I’ll do my best to give you something you can use in your day to day coding activities. Being so simple, ADD gives you a lot of room on how to implement it for a specific area, as long as you respect 2 simple rules:

– at any time you can be only in one realm, being it Assess, Decide or Do
– the quality of the implementation is given by the Flow, or by the smoothness you achieve in traveling from one realm to another.

If you’re new to my blog, or never heard about ADD like this before, feel free to read the introductory series.

Assess For Programming

The assess realm is where you find out how your product / service will fit in the real world. Most of the time you already know that, because the client gave you some specs. In that case you can safely switch to the Do realm, and start coding. But there are situations in which you have to write something from scratch, to implement a new idea, to create a completely new service. Assessing comes especially handy in those cases.

In my experience I found at least 2 ways to speed up the assessment process: one is mind mapping, the other is role playing. At some levels those two can overlap.

Mind Mapping

One of the big advantages of mind mapping is its multi level structure. You can create a document with multiple levels, all accessible from the same point of view. This is especially useful in programming, since the initial phase of every new software project involves a lot of levels, from prototyping, functionalities, user interfaces, architecture and so on.

I find mind mapping to be especially useful for capturing new projects ideas. New ideas have this tendency to pop up in the most unexpected places and at the most unusual times. So, I keep my mobile device, which happens to be an iPhone, packed with a mind mapping application, which happens to be iBlueSky just in case. I think that 75% of my new ideas come from mind mapping them first in my iPhone.

Role Playing

Most of the time you write code for somebody else. The man who pays the bill is usually the client, but the real user of the app will not be the client. The real user will be the one who uses the app. One of the most interesting ways in assessing your programming is to do some role playing. Impersonate the user. Try to act and do as he will act and do. In the initial phases of a project, role playing is fundamental as it will reveal many of the functionality you didn’t even think at.

Of course, not all the time you’ll succeed, this is why outside focus groups are usually the next best thing. Unfortunately, focus groups are pretty expensive. One cheaper alternative would be to use a community of beta testers, usually created in some social networking sites like twitter or facebook. It’s a little bit unusual to use beta testers for prototyping, their role comes a little bit later, but if you can get together a team of fans or close friends to help you with this role playing game, that would turn out to be a very good asset.

At some point, role playing and mind mapping will overlap. You can start with a mind map about the interface and create several branches for each type of user you can imagine. You can role play with a mind map too.

***

Now, we talked about how you can assess, but nothing about what you can assess. One of the reasons for being a little bit cautious is the fantastic diversity of this topic. You can’t really create a cheat sheet of what to assess on such a divers field like software development. You can’t create a “one size fits all” approach here. But even if the software development area is so huge, I think we can find some common ground. Take what follow merely as an orientation map, rather than a cheat sheet.

Goal

  • what is going to do the app? (usually in one phrase: Office is making text processing, Photoshop is making image editing)
  • what is the problem that the app is going to solve? (some software creates more problems that are solving)
  • how long the app is going to “live”?
  • where is going to live? (operating system, device, programming language)

Features

  • are the features atomic? (you can do the same thing from two insertion points?)
  • are the features congruent with the goal of the app? (over packing with features)

Architecture

  • if there is an OOP approach, class definitions, if there is a procedural language, function definitions
  • modules / screens / menus
  • semantic grouping of features (same like modules above but in a more abstract way)

Interface

  • functionality wiring
  • windows / buttons / links placement
  • insertions points

Post launch behavior

  • there will be some support?
  • there will be updates? how often?
  • there will be a constraint for some operating systems / devices?

Unless you already have in place a more formalized process for assessing a software project, that should give you a start. It’s important to mention that some of these sections will be re-assessed after a decision.

The “Decide” Realm – Backfiring

One of the most important characteristics of this realm (from an ADD point of view) is that in the software development, any decision will most likely backfire you at some point. Unless your assessment has been perfect, you will be facing some serious issues with your decisions and will talk about the reasons for that in a moment.

But first of all, what you decide in software development? Well, everything you assessed in the previous realm. In a perfect world you should have  a list of features, hundred of prototyping wireframes and a ton of crystal clear specs, and then only chose from them. In practice is not that simple. Not always the user interface will agree with some functionality and not always the architecture will be totally compliant with the operating system or programming language.

Decision in the software development process should be more close to compromise than in any other process. If you look for black and white decisions you will shoot yourself in the foot, sooner or later. And the main reason for that is the speed of technology. If you chose something now, you can bet it will be obsolete in 6 months. Your decision will be outdated. So, instead of looking for the perfect decision, you should look for the best decision in the moment.

There is no other field in which change is so present as in software development. Every 6 months a new technology appears and the change is fantastic. The users are changing behavior every 2-3 years. 5 years ago link directories were huge. 3 years ago hi5 was riding the wave. Now it’s Twitter and nobody really knows what it be tomorrow. The decision of staying with a specific platform will always be questionable.

That being said, let’s see how you can implement a consistent decision strategy.

  1. Think in milestones – In software development, milestones are called versions. Limit your decisions to the next available version. Don’t plan too far, don’t plan to loose. Limiting the decision to the next available version means promoting the features and interface changes for a limited timeframe. Only until the next version.
  2. Never change a decision until you implemented it – That comes from personal experience. I developed a web platform with hundreds of thousands of users and millions of visitors. At some point we decided it’s time to upgrade. But after a while we decided to stop. That was a mess. We should have follow the initial decision and after implementing it assess our success or failure.
  3. Make the decision transparent – if you work with a team, communicate the decisions often. if you’re an independent developer keep a journal of your decisions. You already may have a tool for project management, but it’s especially useful to note not only the overall progress but your decisions.

The “Do” Realm – Writing Code

The “Do” realm in software development consists in writing code. Yes, that’s everything you should do. You know the features, the interface, you decided what you should do until the next version, so everything you have to do is to write code. But every guy who wanted to write a “Hello World” program knows that things are way more difficult than that.

Usually, the “Do” realm is very close to the “Assess” realm in software development. Every time you finish some code, you go testing and see if everything is ok. And you do that constantly, until you reach a certain milestone.

The main advantage of using this ADD framework is that you presumably have everything ironed in the first two realms, Assess and Decide, and all you do now is writing code. But you will go back to the Assess and Decide realm pretty often, until you reach a certain level of functionality.

***

Do you have other experiences with software development? Do you find value in this post? Do you have something to add? I’d love to hear about that in the comments.




2 thoughts on “Assess – Decide – Do for Programming”

  1. Great post Dragos and thanks for the mention of iBlueSky again. I think the combination of mindmapping and role playing is particularly powerful. Role playing is essentially what you should be doing when writing “user stories” in agile-speak.

    It’s always good to stop and ask “why?” too. We all use software everyday that is packed with half-baked features and un-necessary complexity. It’s as though the developers rushed into the implementation before anyone stopped to ask “why?”, “will people actually use this?” and “is there a good trade-off here between added value and functionality vs. added complexity?”. This is something we always try and do on a continual basis here at Tenero and we hope it’s something that will help our products to stand out.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.