How to convince the developer to take shortcuts
(and why it’s good for your project)
It’s not unusual that a lot of the effort put into a project ends up in the bin. Sometimes it’s unavoidable, but more often than I’d like to admit it’s due to unnecessarily overdoing things…
What’s more productive: writing a complicated code that can be used in many different projects as an asset, or writing a code only to match the requirements of a single project?
The first solution requires more time at the beginning, but it comes with the potential to save time later. It’s also much more comfortable as back-end developers can focus on a single task, with a better chance of achieving good results. On the downside, it’s really time-consuming and you have to be aware that this single task could delay the whole project.
The second option is slightly more frustrating for the design and development team as chances are, they’ll have to do the same thing all over again in the next project. But then again, when a project has only limited requirements, they can finish writing the code in a short time. However, once they’re finished with writing it, there’s often a fear of new requirements — from the client or user side — and insufficient options for these requirements in the solution that they’ve developed.
It’s better to do less, but properly.
We’ve tried both options in our big and small projects. And from my point of view, the most productive solution is described as “leap and lean”. This means writing short parts of the application and deploying them regardless of limited options. After we do this, we can check if more options are really needed, and if so, we’ll be prepared to make an update. In this way, we can meet our client’s and/or users’ expectations and save a ton of time.
According to MVP methodology it’s much better to verify our assumptions at the beginning of the project than to test the finished one, as it’ll be much harder to make changes then. It’s a good practice to start with MVP as a proof of concept — a basic product that makes it possible to define the real needs of the client/consumer. But It’s a common mistake to treat this phase of work as a user-ready product. In our case MVP is an approach that let’s to focus on core features and develop the project around them.
Focus on one core function and make it a strong point in the project.
Steve Blank typically refers to minimum viable product as the minimum feature set — the set that has only the core features that are sufficient to deploy the product. But still, this minimum feature set can’t be a dud full of bugs… We can save time by limiting the features that we work on, but the ones that we focus on have to be done properly.
Since “good” is based mostly on your feelings, it’s hard to tell if your work will also be considered “good” by your audience. Instead, we can use the term “useful” — it’s much more precise and lets us rate our work in a non-judgmental way. By thinking about what is useful, we’re able to limit our work to focusing on necessary features without sacrificing quality.
Don’t over-do things. Keep in mind the real project needs.
It’s counterproductive for a team to write a complicated solution just in the hope of reusing it sometime later.
Although using ready-made bricks is much faster than writing an entire thing from the roots, building them is highly time-consuming. What I’ve learned is that our assets are hardly ever used — and even if we’d like to make use of them, they have to be adjusted to fit the new project. Requirements of changing technology impose constant progress and modifications. Ability to adapt fast is the main advantage of small teams, that we can’t afford to lose - and sticking to old solutions will only slow us down.
