Lessons Learned Shipping Apps

I shipped my first app Trapeze to real paying customers in January of 1987.

Yes, that’s thirty years ago. Man am I old.

Over the years I’ve worked on and shipped a lot of apps, and delivered app like projects. Although every industry and type of app may be different, some things stick out as being important, or at least worth considering.

These lessons may seem simplistic but I’ve noticed that the more projects do these the more likely things will work out well.

(1) Be liberal at the start of the project and conservative towards the end.

The time to take risks is at the start of a development cycle, assuming it’s reasonably long. That’s the time to try new tools or frameworks or languages. The closer you get to the end the less you should consider something new. Sometimes you have no choice, like when I had to ship an app on iOS 7 launch day, but unless there is an unavoidable reason, don’t do it.

(2) The fewer the people—not just programmers—involved the more likely you will succeed.

Big teams need way more processes, planning and time. The difficulties of disseminating information, knowing what is happening, and understanding state is hard to overcome even with massive effort if there are too many people involved. It’s always better to work with a small team that can communicate directly with each other. I’ve done very large projects with only handful of team members.

Big companies (like my present employer) generally fail at this, as company politics and empire building force too much specialization to have small cross functional teams.

Small teams—when given flexibility in how they work and make decisions—can get more work done with less waste. Handicap them with too much control and process and you lose all the benefits.

(3) More flexible processes always beat more rigid processes.

Agile means flexible. Agile with rigid unmoving processes, detailed planning of every task, and central control is never really agile, though people still call it that. It doesn’t have to be chaotic, but it needs to be able to change directions, make changes and try something else without endless meetings and detailed agendas. Building software is never easy—why make it harder than it needs to be by process getting in the way of progress.

Obviously if the team is very large you may not be able to be so flexible, but that’s rule #2.

(4) Constant informal communication between everyone involved is always better than meetings and status reports.

No one likes meetings or status reports. If your team is small enough you can avoid it all by having direct communication. If you are co-resident get used to talking a lot, or use a tool like Slack or whatever you like. It can be annoying to talk with people all day long, but it is actually more productive as you can ask and get an answer right away instead of waiting for some future meeting where the agenda may not even get to your question.

Back 30 years ago we didn’t have tools of any kind but my team was in the same space so we talked all the time and made adjustments and plans as we went along. It might be hard to get used to but it helps optimize the work.

(5) QA/testing should always begin and continue from the start with development, and the whole app should always be tested not just the new things.

If there is anything I believe in it is this. I learned early on 30 years ago that having quality testers who worked with the development team from the first day anything functioned is an enormous benefit. Over time they understand the product better than any of the programmers do, they find all the dark corners, and can even help find UI/UX that is irritating. Building Deltagraph from 1988-1994 (5 major releases) we had a full time tester who tested it all day every day. We had to ship on floppies with no chance of any patch disk and we never needed any.

Compared to this knowledgeable testing, throw-it-over-the-wall testing (like we have at my present employer) is terrible. Generally the testers don’t know much about your app, rely on potentially spotty documentation, communicate very little other than with “tickets” and you have no time to fix anything.

Quality is always best measured at the customer but you want any problems found as soon as they happen, not by them.

(6) Features and deadlines should be mutually dependent on each other; i.e. you can’t get everything you want all the time.

Another terrible practice at many big companies: everyone wants everything always. You cannot constantly add features and leave the deadline fixed. If you want a hard deadline you have to be willing to cut; if you want all the features you have to be willing to wait. I find it amazing when I see people insist that you can do both.

I think of this as a clown car: sure you can keep stuffing clowns inside but eventually it will explode and shower you with clown parts. Likewise if you keep insisting on adding to an app but keep the schedule the same, you will get terrible quality and potentially angry customers.

Sadly I am watching this right now.

(7) People who care about your product and company are always more productive than external contractors only motivated by money.

You should always try to have people who care about your company and your customers work on your software. If it touches the customer it should be owned by you. Contractors can be OK if they are motivated individuals, but hiring bodyshops to fill in your team, or even worse use a company who provides random people you never meet, all you get is unproductive people who simply rack up the hours.

I know of a major airline where their iOS app is horrible and has thousands of 1 star reviews, and it was built by such a company. They decided to hire the same people to build a new app and when I talked with them they were mystified why so little progress was being made despite the deadline being only a few months away. That was 14 months ago and still I don’t see it shipping. At one time that had a real team but decided to “save” money by outsourcing and eliminating all knowledge in house.

It’s not that you can’t hire terrible people or manage them terribly or make many of these errors and still get nothing good, but finding people who care and letting them be productive is far more likely to result in a good product. In the end it probably costs far less too!

(8) Honesty is better than wishful thinking.

Generally I always want to tell people what is going on, what is the status, where are the problems, what we could do. In many companies this is not popular, you want to hide any issues or ensure others are blamed. Often upper management people are treated like demi-gods, not to be bothered with problems, freeing them to look at the “big picture”. Of course what happens is that when things go bad blame flies in all directions. It’s not that all leaders are interested in what is really going on either or have the slightest idea what to do. Relationships between those who lead and those who build have to be built on mutual honesty and respect otherwise you wind up with blame explosions and not successful projects.

I never said this was easy!

In small teams this is much easier but when you are part of a large organization it might be impossible. When Alan Mulally took over Ford a decade ago in his first meeting with his executive team he asked for status and no one said anything bad. Of course they were going out of business and it made no sense, but they had been trained to hide issues previously. Once he let them know it was OK the problems poured out, and he was able to find ways to fix things and keep Ford from needing a bailout. It’s hard sometimes to get this to work, but in the end you can’t fix what you don’t know, and you if don’t care to know it will probably bite you eventually.

(9) Prefer flexibility over hard estimates.

Estimates are always wrong. Assuming estimates are always correct and making hard plans based on them is even worse. In the history of programming (which I have now been involved for about 50% of that history!) I doubt anyone ever got an estimate of anything reasonable complex correct. Even estimates in a Scrum iteration are rarely all the correct—multiply that by a dozen teams with mutual interactions, continuous change requests and external technology changes and your estimate is basically a random number. People are constantly being asked to work 100 hours weeks to meet a random deadline. It doesn’t work and it alway turns out terrible.

Software takes time and often you don’t know how hard it is or what the correct way to do it is until you’ve done it or at least get far into it. Making estimates based on some written “requirements” is at best an educated guess, and more commonly a random value. Now take 100 of those and add them up to generate a deadline and all you did is a glorified dice roll.

Scrum is supposed to deal with this but often it becomes a tool for management information and less about an agile process. I’ve always preferred a lean approach, even back 30 years when Agile wasn’t a term (or Waterfall for that matter). Flexible adaptation to what the progress is telling you, adjusting the schedule or functionality based on what is more important, and a willingness to change when it is necessary usually results in a good product instead of a hurried mess and burned out team. The Most agile Project I Ever Did is one of my favorite projects and a good example of being flexible.

(10) If you are having fun building—and shipping— an app, you must be doing something right!

Programming is hard work, but if you really enjoy the project, your team members and care about your customers, then it will likely be reflected in the quality of the product. The best products and teams I am been privileged to lead or be a part of have always had a good time doing it. If everything is a pain and you are working 7 days a week and all you do is attend terrible meetings and you hate to go to work in the morning, then it might be telling you something.

Of course your mileage may vary! Possibly some of these points don’t apply to you, or you have found a way to get things done anyway. In every industry, type of app, or other situation you may not be able to do all of these things. In my 30 years of shipping apps to customers it has not always been ideal either, but these things appeared important in the successes, and the failures seemed to be missing some or all.