Replacing legacy systems typically starts with an excitement, proceeds through months or years of work, and results in a failure. The incremental strangling of the old shop.netcom.no is a very different story and the approach is rightfully called "extreme" by the rest of the organization. Read on to learn how we have been replacing the legacy webshop one tiny bit at a time. I also hope to share my continual amazement at how much work can be postponed to be able to deliver a "feature" early.
A part of the series Nettbutikk Team's Experiences and Experiments
Nettbutikk.netcom.no is the best project - though I rather say product development - I have ever been to. When asked why, this was my answer:
Full stack & full control: frontend, backend, ops. Great people & ideally small team. Very pragmatic, minimalistic and evolutionary approach to the dev process. Working closely with the business and seeing the app actually matters to them and influences real people every day.
There are many things I am excited about in this project but today I want to focus on one thing.
Normally when people speak about their favourite project, they brag about what they did. I want to brag about what we have not done.
One of the great things about this team is its minimalist mind-set:
NetCom had - or actually has - this huge, inflexible webshop rented from a 3rd party and customized. But the business wanted something different, something that would actually fit their needs, evolve continuously, enable them to experiment. Something where the time from an idea to production wouldn't be months but days or hours.
So they have decided to get a few skilled developers, having them sitting together with the business (instead of being outsourced) and writing their own webshop.
To me this sounds very scary. As far as I know, most of the "let’s ditch this non-trivial software and write it from scratch" projects fail badly.
And when you think about it, you need a lot to implement a webshop:
This sounds like at least 1 year project with a big-bang release at the end. You cannot release half of a webshop, right? You can’t release a perfect webshop without checkout, where people can’t actually buy stuff.
Product details page of a single product variant
Well, our first release was a single page - product details of one variant of one product. We have released it in just a few weeks (though more than the two I hoped for).
So you would navigate the old shop and when you clicked on iPhone 6 plus 16GB, you would come to our page. You could select a color, subscription, ...
... services and accessories. And when you clicked on the "Fortsett" button, you would go to checkout in the old shop again. And even the "shopping cart" - the configuration of your order - would mostly just reuse the shopping cart in the old shop via an ugly iframe hack.
Later, we extended it to all variants, all iPhones, eventually all phones, phone listing, all product types, ... .
Nowadays, 10 months since start, we have everything, only the checkout still lives in the old system. (And we are looking forward to getting rid of it as well!)
How do we do it? How do we trim the next chunk of functionality to the total minimum? We apply these techniques:
You Don’t Need It Just Yet. Postpone it!
The key principle is "You Don’t Need It Just Yet". There is a lot you truly need, but most likely it can wait a day - or a few weeks (and you can hardcode it or do it manually in the meantime). The magic words "in the first phase [or day]" (and, possibly, "experiment") can help you to get this across to the business people that are always eager to get more cool stuff out. (And, of course, by doing less now we get eventually more done!)
It is also very important to remember - and to communicate to the business - that you only need not to be worse than the existing functionality - improvements, bug fixes, and additions may wait. (Even though we more less managed to follow this maxim, everything we did is better and performs better than in the old shop :-) .)
I am constantly surprised how far we can get with these. It works best when having colleagues that challenge you on doing even less, on hardcoding and doing manually a little more than you would want to. (We are developers after all, we love automation!)
Do I need it now?
(Hint: Most of the time the answer is no.)