Skip to main content

Choosing the right project

Not every project is a good one. Before you start putting hands on the keyboard, think carefully about whether the project you're going to embark on will succeed.

Interview authors need to think about:

  1. Whether they are just automating a bad process, which will remain as painful on the computer as it is on paper
  2. Whether they chose the right part of the project to automate (scope)
  3. Whether automation will significantly improve the process in some way
  4. Whether the project has a chance of succeeding in the real world.

Paving cow paths​

It's apocrypha, but rumor has it that the famously confusing streets of Boston are a result of letting cows wander and then paving the very paths that they created into streets. In the IT world, paving a cow path means taking an existing process and replicating it in code, without considering if the process itself can be improved.

App developers can be guilty of this, sometimes as innocent bystanders who are trying to improve a process created by the courts, a legislator, or a government agency. Still, sometimes energy is better spent lobbying one of those groups to improve the process than automating it as-is.

When you are assembling a particularly bad form, it's worth talking to court clerks or agency representatives to find out if they'd accept your alternative version of it that makes it work better.

If your job is automating forms, try getting a seat on the court's form committee. These tend to open up regularly. They may appreciate hearing from someone who has thought about the forms in such depth.

Scope​

It's best to start with a small scope, and then build out. Even then, take time to give yourself a reality check every so often. If the project is never-ending, see if there are features you should eliminate or postpone to get something out into the real world. A feature freeze is a healthy thing in every project. There is no substitute for the feedback of real users. Delaying your project to add a "critical" feature has less value than releasing a smaller project and seeing how your users react.

Choose a reasonable scope, and then communicate it clearly throughout your app. Over-broad projects can:

  1. Never be completed
  2. Be very difficult to maintain and update when law changes
  3. Mislead users, if they seem to cover an edge-case that they really don't

Value add​

Is your project greatly improving the user's experience? Or is it simply letting someone use a keyboard instead of a pen? Keep in mind that a pen is a very intuitive user interface, and even the best computer interface takes more cognitive load. An app with no value add can in fact be a negative.

Good apps:

  1. Save the user significant time and effort
  2. Eliminate redundant steps
  3. Hide confusing and irrelevant branches when they don't apply to the user's situation
  4. Provide guidance along the way
  5. Make use of external knowledge about the world, where appropriate. For example, matching addresses to courts, or auto-completing fields based on the user's location.

Feasibility​

Sometimes even the best app will wither on the vine. Think about whether your app will succeed.

Do you:

  1. A place to host the app at a reasonable cost and with a reasonable amount of staff time required to up keep?
  2. Have a client base that can access the platform you chose to use? For example, does it work on a mobile phone (which is the only way many Americans can access the Internet)
  3. Have buy-in from the communities that can help promote your app, such as third-party vendors or social service agencies?
  4. A way to keep the app up to date when the law changes in a year?

Further reading​