When you go through school you’re always taught to do your best, to try to make the thing you’re working on the best it can possibly be. When it comes to software we naturally want the same – we dream of something that’s fast, accessible, responsive and free from any bugs. It’s just not realistic.
Need for Speed
In the real world of web or software development, speed of development is key. We have to deliver functionality by deadlines. This might be because users need it for a fixed date, or maybe you need to move quickly to make the most of a gap in the market, or you need to beat your competitors or keep pace with them – there are many reasons.
Let’s say we’re adding a new feature to search and filter product data. We’ve estimated that the full feature will take 4 weeks. However, we can deliver a very basic search box that just matches all product text within a week. We can actually deliver about three quarters of the value to the end user in one quarter of the time.
The need for speed means that we can’t take our time and build the perfect solution. We need to be fast and that inevitably means compromising and cutting corners. It’s OK to release something that isn’t perfect. It’s even OK to release something with known bugs.
By getting the code into production and letting users try it out earlier we can use their feedback to steer the rest of the feature. Maybe after the first release we realise that this is all they need and we don’t need to build the rest? Maybe it’s too slow in the real world and we need to go back and improve this before adding more complexity? Maybe the known bugs are not quite what we thought they were?
This is general agile development, starting simple and building in iterations, and is largely about good planning and communication. We can apply the same kind of thinking to the coding.
Can we get away with a hard-coded list or a static JSON file for now instead of creating a new database table or API?
Can we select defaults on dropdown lists or radio button groups so we don’t have to add required validation?
Can we use browser storage rather than writing to the database?
Can a form just post key-value pairs to an email address to begin with while we’re working on the database?
We don’t need polished design or animations until we know the solution is right.
I’m sure you get the idea. Not perfect, just good enough. Go fast, hit the deadline, listen to feedback and improve it when the pressure’s off. If you’re releasing something that you feel is risky do it under a ‘BETA’ or ‘Experimental’ flag so users know what to expect and it doesn’t damage your reputation.