You Can Build Software Too

A common misconception in software development is that you need a programmer, developer or any other similar name that sounds technical. Sure, we read books on the subject, attend conferences, conduct lectures, and compile our fair share of bits, but the truth is that a good deal of building software doesn’t involve programming. Actually, most of it isn’t programming work.

Building software involves rational thoughts. This presumes the point that you have a compelling interest in building software. I suspect that if you’re reading this blog post, then you have some stake in the topic. With a few pointers in the right direction, you too can be a contributing member of the software development team.

Let’s start with a fresh project, contrived especially for us. Software automates tasks that you might otherwise do with pen and paper, right? So begin by asking, or more importantly, writing down some questions. Here’s 20 to start; all related to the pen.

1. Who would hold the pen?
2. Where does the pen belong?
3. How many pens are there?
4. What color is the ink in the pen?
5. What do you do when the pen runs out of ink?
6. What if its too dark to see what you’re writing?
7. How can you tell if the pen fits your hand?
8. How long do you have to use the pen?
9. Who is protecting the pen from thieves who like to steal pens?
10. What happens if you lose the pen?
11. Are you using the right pen?
12. What kind of pens do others use?
13. Should your pen have a clip for your pocket?
14. Should you be wearing a pocket protector in case your pen drips ink?
15. Is a clicker pen better than a pen with a cap?
16. Why is a pen better than a pencil?
17. Can this pen write upside down?
18. How long should you expect this pen to last?
19. How much do I have to write to make a profit?
20. Should my pen make check marks from left to right, or from right to left?

Building software is a lot like this type of interrogation, rationalization, recollection from prior experiences that went well or poorly and the overall willingness to ask questions. You might apply the questions about the pen to a web site, an order form, or a new iPhone application. Curiosity is a good, succinct requirement for building software. If your goal is to build good software and your curious about your subject matter, you can be a valuable member of the project team.

It’s not really about deciding between ”for loops” or “do while loops” or even about calling complex database queries. Don’t get me wrong, we still do that and gosh, its one of the coolest things I do, but today’s technology makes that such a sweet and pain-free experience that the real job is understanding your problem domain. This has always been the problem domain. You reach an understanding of the problem domain by asking questions and writing down answers. You don’t need to be a developer to have an impact.

Lastly, the document that asks and seeks to answer these questions really ought to be written in the domain of the given business problem. It won’t have any technical implementation details, so by definition, anyone familiar with the business should be able to read this document. Again, this presumes you have an incentive or interest in reading documents. If you dislike documents, contracts, processes or business rules, then you’ll probably self-select out of the situation. If you’re wondering where to get started, imagine that your the prosecuting attorney on a case and the business problem is in the witness chair. What questions would you ask them?