One of the most important things we teach the junior programmers who join the Semaphore team is the mindset of shipping in small iterations. This is a simple concept, however there's an inevitable misunderstanding that stems from the subjective ideas of "small". Thus, in practice we need to teach by example what we really mean by small.
When you're inexperienced, the desire to do and show your best work often leads to perfectionism. In programming, perfectionism manifests itself as "I haven't submitted my pull request because I haven't completed everything yet".
Perfectionism is at odds with the goals of developing business software — giving something useful to users, preferably sooner rather than later. Perfectionists create imaginary obstacles and never end up building anything.
Recently, a pair of junior programmers was building a new reporting screen for our marketing team. The screen needed to combine two sources of data for a given time range and present a paginated view of results. The team that needed the report has never seen the data this screen would provide. Would it hurt if the first version of the report did not include a date picker and pagination of results beyond the top 25? Hell no. So, we encouraged them to ship the screen without the date range and pagination. The initial results provided more than enough value and ideas for improvement. The marketing team had some data they could work with while the developers continued working on the remaining tasks.
The crux of the matter lies in decomposing a task into minimal useful pieces. Next, you estimate the complexity of each piece and communicate expectations with the "stakeholder" (customer, client, product manager, or feature user).
Say a designer has recently updated several details that affect four distinct screens. Would it be best to integrate these changes in four separate pull requests, or one? This is where complexity, i.e. the time it would take to complete each one, needs to be considered. If they would take a day each, four separate pull requests are probably best. If all of them together would take you less than an hour to complete, go ahead and combine them all into one pull request. Are three tasks really easy, but the fourth one requires additional input from the designer who's having a day off, as well as more time than all others combined? Best to please your users with what you can finish soon, and then do the last thing separately.
Shipping early will often provide you with surprising feedback. Perhaps the initial version is so good that nobody really needs the stuff that's "missing". Or, the whole idea didn't really deliver what was expected and needs to be reconsidered. The goal is to learn and help others. Just keep moving.
Top comments (7)
Great stuff here.
We've been bitten occasionally by shipping an imperfect thing and then being pulled off entirely and never iterating. We've had to develop the discipline to build on the first imperfect fix.
Is this something you could write-up? I'd love to read about it. It's certainly difficult to deliver agile in risk averse or highly polarised environments where things live and die on the initial iteration, but ultimately you might be fighting against "run once, run away" as an agile coach recently termed it in a twitter discussion, not so much internally as from users.
Perfection is the enemy of good
If you don't get customer complains, you overdid it.
Absolutely. If there is one thing I could add it would be to try to avoid committing large changes just because it's faster than many individual commits. You don't need to deploy from master, or deploy every commit to production.
It happens with me lot of time
This is good stuff