Deciding what software to write

I found myself often asking this question: what to write? Scoping the project is fun, at the same time could be very challenging. I know that if only I have infinitive time in my hand, I would develop a software nobody would even image in the wildest dream. The truth is I do not have infinite time in my hand. In fact, time is so short and limited; I must make sure that every minute must be counted. So, where to begin to cut down (sacrifice)? Or better question what is the bare minimum requirements for the software (I use software and website interchangeably) to be considered satisfactory? As Eric Reis explains his excellent book The Lean Startup what would be my minumum viable product which allows my and my team to collect the maximum amount of validated learning about the users?

Trimming down features

What good purpose it serves if the software doesn't do what is suppose to do? You may build best possible looking website aesthetically, but it doesn't convert... Engineeringly masterpiece software application which doesn't do what it is required to do... The effort, the time put into the project, consumed caffeine, used brain power; all would be wasted if the software doesn't live up to its functional expectation.

Before diving into details, I would gather information by asking simplest question that I have found What do you want to achieve by employing this software? In other words, what do you want this software to solve? Often, I know the answer, but it doesn't hurt to ask stakeholders one more time.

If it's a website, especially transactional one, answer is so simple, yet sometimes it can be overlooked; convert more prospect to buying customers! Everything else is sub-goal, and it is okay if they are not achieved initially. Same goes for applications; if the application doesn't help make more sales or if it doesn't assists overall company goals it may not be worth to write. Unless you work for a project which has other concentrations other than sales; such as personal satisfaction, moral, social, scientific or other reasons. Generally speaking, those are not my cases.

Cutting down from non-functional requirements

I haven't seen anybody likes to have slow or constantly crashing software. So, the user stands point of view; it must be fast, responsive and highly accessible. On the other hand engineering stand point of view; it must be secure, extensible and maintainable. Nobody would argue the necessity of ever growing non-functional requirements.

However, if I go back to my first argument; if the application doesn't satisfy its fundamental functional requirements (it could be making more sales); there will be no use for it. Therefore, it may be the best place to start cut-down. However, by no means, you need to write software full of technical problems. Rather, write software simpliest way for non-functional requirements while you don't even know the project would be considered successful. Default security settings, quick access to data, organizing the source codes for future use, etc. actually a good place to start before spending countless hours putting bank-level security systems, writing robust caching mechanism or coding spaghetti style. There is no excuse for them...

What makes any good if the software generates most comprehensive sales report if there are no sales. Another example would be, if you write an e-commerce application with a polished reviewing system in place, however, there is nobody purchased anything to review for. Supporting multiple warehouses while you have only one warehouse, implementing another country's tax system while you are only serving to one country at the beginning. It's good to have an idea for future growth and direction but, the first goal is to make a software which supports current situation.

I, only focus on the first day the software started to be in use, everything else is a future project. Even it's required one month later, I cut down; because I will have another one month to write it.

Cutting down from nice-to-have features

Supplementary features which are helps to the overall functionality of the software often very time consuming. For example; partial order fulfillment, code optimization, or application personalization. I consider all of them nice-to-have features. Yes, if Amazon or Google or any other well-known company have a compatible software; chances are they have all those nice-to-have features maybe even competitor have it all. But, it doesn't mean my software needs to have all of them at the beginning.

Deciding what is main functionality what is nice-to-have might be challenging. All may seem must-have, but reality is most of the features are not be used by all the users. The question is what features are definitely be utilized by the majority of the users? If the software can support multiple languages, it's awesome, but if there are only two people who would use the feature doesn't mean you need to write a multi-language application.

If I misjudge what is nice-to-have what is must-have; short after the initial launch I would know. I don't keep a list of those features, rather they can get to the point where I would know by heart. That would be the time I implement those features. Until then, I keep them out of my mind.

Knowing user

Requirement gathering meetings are certainly important and reveal tons of information. However, it's equally important to know actual user of my software. Either it's a website, mobile app or application most likely I wouldn't be the use day in day out. That's why it's important to know the users expectations, their behaviors, and level of expertise. Stakeholders have an idea of requirements but in reality, they are sum up what real users want with an addition of what they want to have.

Threading users as a novice, non-tech savvy user general receipt for successful software. That means, sometimes going an extra mile and make it simple for the users and explaining every stage. If I found myself in a situation where I try to convince myself "they must see this button to click" or "they should understand what is on the screen" then it means I used a shortcut. Therefore, I add those extra miles into the minimum final product scope. Even knowing basic demographics of the users helps me deciding what extra miles I need to go; while keep in my mind that all users are non-tech savvy!

I generally work in the area where I have extensive experience. However, if I come across a project which I have only limited knowledge, then start read, listen, watch and absorb actual users to increase my knowledge base. Sometimes I spend days before finalize the requirement gathering stage.

Conclusion

The question was what software to write? Developing software is the balance of imagination and reality. Here is my recipe; I start with imaging software I would write if I have infinitive time in my hand; that is the ultimate goal -a goal probably never be achieved.- I leave the Alice Wonderland and come to the real life and start trimming down. During this process I keep everybody in the loop, so everybody would more-less have an idea what will be the first phase of the production.

  • Gather absolutely must-haves
  • Image (seriously, just image); best possible solution you can produce with the given arguments
  • Define specific goal of the project
  • Reshape the expectations
  • Keep simple yet "does-the-job" list of non-functional goals
  • Postpone all "we-will-need-later" features
  • Take out "nice-to-have" features from the list for good
  • Put in the consideration how real user would use the software and take the extra miles to make it self-explanatory