An experience I’ve had to deal with a lot:
Don’t ship, before you build your boat. Said differently: Don’t set for sail before you have a boat. This is common sense (or is it?). In the physical world it’s impossible to ship before you build your boat. Imagine sailing for sea, and in the middle of the ocean you only then realize you don’t have enough food, supplies, parts, to get anywhere. That would be horrible. For some reason, perhaps since programming is more of a mental exercise than a physical exercise at sea, many programmers don’t take the necessary precautions. The practice of coding should actually visibly teach us not to have assumptions. Segfaults, buffer overflows, SQL injections, a misplaced comma or semi-colon show us that daily.
Too many times as Engineers we get excited (very excited) at solving problems and after thinking through the problem we quickly decide to start building. We have an idea of how to solve the problem, no time to waste, we’ll figure things out along the way.
Imagine such a programmer spends two days building out the basics of his app only to find out two days later that his app will use a significant amount of memory and will increase the costs of maintaining the app.
Imagine such a programmer wants to build an Android App but using C++. The programmer knows that Android can listen to C++ libraries. After a few days of coding in C++ the programmer finally finds out that Android, to work with C++, requires the C++ code to be in the JNI (Java Native Interface) format. Suddenly the project is at a stand still because the Programmer doesn’t know JNI, he only assumed the powerful C++ language could easily be ported to Android. So two days of wasted work.
What is the common problem with the above scenarios? Shipping before building a boat. The programmers mistakenly assumed a boat was there, so they shipped. They assumed there was enough memory, They assumed the required C++ libraries would be easy to port, they assumed a video player automatically encrypted/protected the media in it so they set for sail.
Big, Huge mistake. Ultimately Software Engineering is about Proficiency and Productivity. Proficiency actually leads to Productivity. Few things are more worse than beginning a project without knowing from the start what are the limitations. Not every project requires planning for months, sometimes all you need is a few days, to get something going the right way.
Best practice is to never assume something will be there. Don’t assume people will like your app. Don’t assume people will use your app correctly. Don’t assume there will be enough memory, enough space. As much as possible, an Engineer must be confident that she can solve a problem and must have an explicit, clear way to solve that task.
Take home: Don’t leave your team, project manager, business partners stranded at sea: Don’t set for sail before you have a boat. Don’t set for sail before you know the boat can make the journey.