The Six Goals Of Every Programming Project

When I shipped my first app in 1987, Trapeze, I had no idea how many more things I would be shipping over the next 30 years. In all that time I have been working to reach the same end goals for each project release.

None of these have changed from that first product to today: what has changed is that there are many more ways to get there, or not.

Although some of these might not be relevant to every type of programming, if they are relevant you need to be successful with all of them; it isn’t useful to do some of them well and suck at the rest. Assuming you are honest in evaluating how your project or team wound up these are goals which cover most of where you want to end up.

The list:

• The end user got what they needed, or what they wanted.
• The end user was able to easily make use of what you made.
• The quality, performance, security or other attributes of what you made were acceptable to the end user.
• You utilized a reasonable amount of resources in building it.
• You completed the work in a reasonable amount of time.
• The work was built to be maintained or updated or expanded.

Of course this is the end state (of the product or version): how you get there is clearly the hard part and everyone has their own ideas. Today of course there are myriads of ways to build everything, and making choices is not always easy. This list is useful as a measuring stick of how well you did, assuming you can measure yourself objectively.

First, the user of your software, which may not be a person if you are building an API or service, has to get what they want or need. Note of course these are not always the same, often you ask people what they need and they don’t tell you exactly because they are unable to verbalize what it is. Sometimes people will tell you what they think they want, and it isn’t what they need. This task of figuring out what will actually solve their problem or provide the actual service is not easy. For some kinds of software, need is not the issue, for example games are more about desire (to be entertained or amused or pass the time) and not need. Hailing a ride easily is a need. For some business environments needs and wants are very hard to define.

My first lesson in programming back in 1981 was that people generally don’t know what they want or need until they see it, which makes writing hard requirements up front almost pointless. It means you need to be more flexible, to iterate, to prototype, to let people handle something before it is cast in stone. To get to the end state where the customer is happy, the work to figure out those needs and wants is a continuous process and there are no shortcuts.

The first goal is basically figuring our what you need to build, and may continue during the entire development period.

The second goal is about usability. It’s about design. It’s about availability. If the user gets what they need but are unable to make use of it they will abandon you, or at the very least complain a lot! Design is rarely about how pretty something is, it has more to do with understanding how someone will use what you built, what they know, what they can learn, what they expect. You might have to test your designs, or at least spend time understanding who they are and how they might approach what you are giving them. This is also a continuous process, the idea of a design up front for how your product works with no changes makes as little sense as deciding what it does up front and never swaying from it. An application should be considered as a living breathing thing which can be sculpted until the end result is exactly what is needed.

Like what your product does, how it can be used can only be truly measured by the end user. I’ve always been amazed at how wonderful I thought something was only to find the final user ignored what I thought was important and hated what I thought was elegant. After a while you learn how to recognize what people like. I’ve always been amazed at products I see that people hated when it was obvious the developers never looked at similar products or features from other companies: some things seem to work well and doing something different had better be actually better or people will reject it.

The quality of what you make really does matter, I have never cared for the idea that you can release crap and quickly iterate. Often you get one impression with people and if you give them something that crashes all the time you won’t see them again. If you give people something that meets their needs and is very pleasant to use, and it crashes so much they can’t use it, what was the point of building it in the first place? The game company I worked for found this out before I got there, the game was fun and the players wanted to play it, but it crashed so much that even the most die-hard fan eventually gave up, and they lost 80% of the customers because quality was not important enough.

Quality, which I consider being continuously available and functional, can cover more than just crashes or errors. Security and performance are also quality issues. If the app dies all the time, is horribly slow and your users are being hacked, none of the wonderful features or design matter. When I own a car, if I want to go somewhere and the car doesn’t work, what good is it? If I want to make an airline reservation and the system loses it, what is the point? If I have to continuously relaunch an app and lose data, why will I continue to use it?

I hate having a user of something I shipped even notice the quality, I want them to notice how great the app is, how nice it is to use, how best it solves whatever the need is. I don’t want them to even notice anything is amiss. I am always amazed that the average iOS or Android app crashes 1 in 50 users every day (2%). To me that is terrible. Imagine 1 in 50 cars crashing every day!

All of these end user things are great, but if it cost you and arm and a leg to build it, was it worth it? Of course how many people or servers or equipment—basically money—it took may depend on what you built, but it has to make sense financially in the long run. The Space Shuttle software development supposedly cost a fortune for every line of code to ensure that nothing would ever go wrong, but ordinary companies cannot afford that type of cost. For many projects it might not even be about money, but how many people can actually work together to build something. At my present job we have what I think is 50 times more people than are really necessary, we have more architects than programmers, more contractors than employees, more managers and committees and boards and we keep adding more, all with the mistaken idea that more is necessary. Financially in the end it might be OK but given how long everything takes, I am sure we are wasting time and money we don’t need to lose, simply because upper management seems to imagine more means better or safer.

Smaller teams given more freedom to innovate (assuming they have a clue) are much more likely to find optimal ways of building things; less process, fewer meetings, fewer managers, less scattered communication usually makes for better development. I am amazed that at different times I’ve led or been in teams of seemingly too few people, but with a total ability to decide on how to do things, where we built huge products that hit all the goals. Comparing the travel company I worked at and my present employer is crazy: both apps are not too dissimilar in feature complexity but here we have 50 times the people.

So if you have a perfect app that is great to use and has awesome quality and it cost you more to build than you will ever make in return then your business is not worth much. Of course maybe you can raise billions in VC money and sell your product at a loss (hello Uber) and still make a fortune in the end (maybe), but most of us are not in that boat. Remember that the more people you put on a project, the more process you need, the more managers and the like you have to have, and often the more people you need to add to the project later, etc.

Related to resources is time. If you can’t ship your product when the customer is ready, or the market is hot, or the opportunity is there, then all the great features, design and quality won’t matter, because they went to your competitor. I worked for a little company in just that perfect spot to build a national brand, with one competitor in the same boat. They executed in a timely manner, and the folks I worked for couldn’t build even the simplest thing they needed. Despite having everything else perfectly lined up, the inability to build some not terribly complicated software doomed them. Their competitor was able to deliver, grow big, do an IPO and are a billion dollar company today. As I mentioned before, when I see their TV commercials I want to throw something at the screen. I tried and failed to convince the owners that they needed to change how they did things if they wanted to keep up and today they are still a pleasant but tiny company that missed a perfect market.

How you build something in the right timeframe is of course related to how you use your resources. Make things complicated, have too many people too soon, create processes that get in the way, demand inflexible rules, operate in total chaos, insist on millions of meetings and signatures and approval cycles and argue endlessly about trivial things, and watch the days go by. I still wonder about people who love to make simple things complex, and prefer to build things no one understands, and make decisions for reasons other than getting it done, and then hear people question why they never get anything done.

We all have only so much time on this earth, and no one ever said at the end they wished they had gone to more meetings about the color of the bike shed! Decisions made locally, quickly but with understanding, and by people who know whats going on, almost always result in moving forward at a decent pace. The further decisions are made from the people who have to do the work, the less likely the right one will be made, and the more likely time will be lost. Latency isn't just bad in networks!

The last goal is whatever you build needs to have a decent future. If you build products where the code is incomprehensible, dense, or way too big or complex, the less likely you can rapidly produce new versions. Unless its a one and done kind of product (I knew a company that only built apps for movies, once the movie was out, it was abandoned) every app has to be maintained or extended or altered to meet new needs or wants. These goals are all an end state but also a new start state. If what you build is a horrible mess, then future versions may no longer meet these goals. Sadly I’ve seen a lot of these messes, eventually they either give up and write a new one, spend a fortune trying to fix the old one, or often go out of business. Sure even the worst piece of trash that is still economically viable might be supported for a long time though sheer will and amazing effort, but for most software there is a limit to how far you can carry it.

It boggles my mind that Deltagraph, a charting application for Mac and Windows that I started building in September, 1988, is still alive today. The source code has never been rewritten in now nearly 30 years, and I haven’t seen it in almost 24. How this thing still runs is beyond me, we wanted to rewrite it after 5 years but the publisher wanted to move in a different direction. Somehow the subsequent owners have found some way to updated that old source. I assume it is still financially viable somehow. So you can keep anything going but you wonder how many insane people are left in its wake!

So how do you stack up with the goals? Can you honestly look at what you built and see the end state, or at least the current state, fit right in line? Happy customers with a pleasant to use product that works all the time that showed up right when they needed it that makes you money and everyone who works on it is happy as well, that is where we all want to be.

If you find your self wishing you could measure up to some of these, maybe you have to look at making changes. Making products your customers hate, are hard to use, crash all the time, take forever and cost a fortune to build and update is a great recipe for misery. Yet strangely enough the world has lots of these products. Sometimes you can overcome failure at some of these goals and still make money or at least find someone who will use it with gritted teeth, or get lucky and do an IPO before your bad end goals kills you.

Everyone needs goals in life, and making great software should one of ours!