Inception of an Application

As software developers, we're consistently asked to 'just build this thing'. I used to find it somewhat flattering that people would believe that I could help them realize their dreams. After years of talking to people about their ideas, and occasionally offering to help out, I came to a much different understanding. It was less flattering, and more frustrating. It's like asking a construction worker if they would build you a high rise. Maybe that'd be nice, but it's a dream. Without backing, it's like being asked to help them win the lottery. The person asking often just doesn't have any conception of the time and will that it takes to bring about an application. So I thought I would write this introduction to what it takes to get a developer interested in building your application, and why the magnitude of the word 'just' is staggering.

While this first post is more clearly aimed towards the person that is new to the SDLC (software development life cycle), it may have some insightful points for the seasoned programmer that isn't accustomed to reflecting on why they should build their own applications. Either way, lets hop right in.

When you feel that stirring that you think you might have an idea for a piece of software, you need to start answering questions about it. Usually before you even bother anyone else with it. It needs to become an object in your own mind that you can spend time carefully questioning and scrutinizing. Turning over each facet and understanding what you have, even before you bring it to other peoples attention. These five questions should lay a solid groundwork for refining the startling clarity that you will need:
  1. What is it that you want? Hint: This answer should be personal, and probably long form.
  2. Who is your audience? Apps are not all that different from books.
    1. Why will the audience care? 
    2. How will it save them time, or improve their process?
      Remember: People wont use your software if it doesn't improve their life in some way.
  3. Why is it worth doing, what is going to make it be amazing? Don't be circumspect.
  4. Where will the motivation come from? For you and anyone else working the project.
These are reflective questions, not meant for easy answers. If you believe that you have found an easy answer, then you probably need to go back to the drawing board and keep brainstorming. These questions should generate a lot of thoughts as you really start to understand your idea. Paragraphs worth, perhaps. Once you feel you have a solid understanding, then the next step is to distill these answers down to a 5-15 second elevator pitch. Something reasonably easy and quick for your target audience to understand, but leaves them wanting more. This is not the pitch you should use on developers. Most developers have a finely tuned BS-o-meter, and wont be interested in a sales pitch.

Once you're comfortable that you have a solid pitch, then you should move on to keep questioning your idea with deeper, more incisive questions. While these aren't prescriptive, they're a great starting point for things that you'll definitely need to understand:
  • Who is your audience? Dig in to them. If you think you have multiple audiences, make sure you go over them all.
    • Why do they care? What are their motivations?
    • Why will they use your software daily?
    • How is your idea better than your competition? And don't fall in the pit of 'There's nobody else doing this'. There's always someone providing some kind of competition.
  • Will this software have a revenue stream?
    If yes (and 99% of the time, if you're not the developer, it should be yes): 
    • Where from? Sales? Ads? Grants?
    • Why will they give you their hard earned money?
    • How much will it generate? And don't be coy.
    • Is that worth up-keeping for at least 7 years? Think maintenance and return on investment.
    If no:
    • Where there is no money, there darn well better be a strong motivator. What is it?
    • How will you host and maintain the software if you have no money?
    • How will you get developers interested, and keep their attention?
    • Are you really sure it's worth keeping up for at least 7 years?
  • When do you want it by? 
    • Are you going to need resources/money to develop it? 
    • Where are those resources going to come from?
  • Finally, and most importantly, how will you know when you have your desired software?
These are just stepping stones to get you moving in the right direction at a high level. They're thinking points that will assist you in figuring out what your starting point looks like, and deciding if you are willing to be in it for the long term, and if you'll be able to actually get money out of your product.

If you've made it through this entire process, only then should you really think about involving a developer. Understand that you're talking to someone that can help you realize your dream, but don't imagine you're asking for a dog house, when you're actually asking for a high rise, and remember that they're not likely to build a dog house for free, much less a high rise.


Assembled Best Practices for Software Development

I've been curating a list of my favored practices for some time now. These ideas have come from a variety of sources (books, blogs, coworkers, myself, etc.). These make up some of the best ideas and practices that I have seen in software services. There are a whole lot more that I could talk about, but these are the most important that I think everyone that works in software development should be familiar with. Without further ado:

Understand the foundation. This can be one of the most glaringly obvious, yet oft overlooked, points of an application. Every application has a goal; Something that it aims to do better than anyone else. Generally, that goal leads towards two or three core competencies that the whole platform will revolve around. Make sure you know what those competencies are, and don't ever sell them out, or outsource them. Your evenings and weekends depend on it.

Features are like pets. They're fun! But, they have to be groomed, cared for, and carefully maintained. As such, like pets, you should be very careful about which ones you adopt. Whenever someone says, "We should add.." always start with "no". Make any non-core feature work to be in your application.

Scratch your own itch. The next big thing is a lie, and doesn't deserve your attention. Make something that saves you time, and makes your life better. There will always be people trying to figure out how to force the next application to blow up in to something big. Instead, just figure out what your itch is, and scratch it.

Always Be Shippin'. Too many projects die before they even get off the ground. Figure out what the minimum viable set of features are, and then ship it as quickly as possible. After that, iterate on the design, and make sure you get it in front of your (preferably paying) customers, right away! They'll love you all the more for seeing your software evolve in front of them. Speaking of which:

Love your audience. Your software is nothing without your customers. Focus on their needs and collaborating with them, more than the amount of money, or the contracts that they bring in. When they give you information, respond to it. The most important lesson of sales is to remember this one simple truth: People don't buy a product, they buy an emotion. Make them feel good over and over, and you'll have a customer for life.
The customer always believes they are right. But, they're probably not. That's right. Conventional wisdom is wrong. That doesn't mean you treat them as if they're addled. On the contrary. You should always treat your customers with dignity, and respect, if not admiration. Yet, even when you do that, you should help them understand why your software works the way it does, and don't let them dictate terms that will lead you in to a feature haze. That way only leads to heartbreak. Listen to your customer, ask pointed questions, and act only when it is in the best interest of your entire audience. Never become myopic, as that always has an effect on the picture as a whole.

Build simple systems. Some will find it frustrating or condescending, but building three ways to do the same thing in your system doesn't make you nicer, it makes your system more obtuse. Find one way to make your system do the best possible work, and make it as intuitive as you possibly can.

Estimates are pure guesswork. Don't fall in to the trap if you can help it.  Keep shipping features as you are able. If someone makes you guess how long it will take you to implement a particular feature, imagine how long it will take, then weight that by somewhere between 1.5 to 5 times that number, depending entirely on your own personal expertise and the complexity of the system at hand. If you think something that you're not very familiar with will take you a day and you're dealing with a complex system, don't feel bad about saying five days. If it's something you're very comfortable with it's not complex at all, and you think it will take two hours, go with three. The key is this: Always under promise and over deliver. People may think you're daft when you guess five days, but they'll think you're a miracle worker when you deliver it in two, instead of grumbling about it taking twice as long as one.

Remember these three things:
  1. There are things that you know that you know.
  2. There are things that you know that you don't know.
  3. There are things that you don't know that you don't know.
That last category is the largest of the three, guaranteed.

Finally, the best way to learn is to practice, scrutinize, adjust, and repeat. Don't just keep doing same thing that you've always done, else you'll always get what you've always got.

Code on.