Starting afresh
Some of you may know that I recently started a new position at asos.com. I meant to write about my experiences here a lot earlier, but free time has not exactly been in abundance these last two months. In short: the codebase has its problems but I’m really enjoying it.
First of all: the environment. The ASOS offices are located in Camden, London. This is a cool place to be (the eating to be had around here is simply amazing) and is a convenient 10-minute walk > 15-minute train ride > 10-minute walk from my house (not a bad commute for central London!). The offices are not quite as nice as those at my last company, but that place was pretty hard to top:
- The main atrium
- The escalators up from reception to the “Sky Lounge”
- The reception for my floor
.
Asos looks more like this:
- Upstairs seating area
- Behind the reception
- The cafeteria
- The main atrium
It’s very white and arty, and it just feels a little cold compared to my last workplace.
As for the code? Well it’s in a better state than the code was at ParkerFox when I started there, but it’s worse than it was when I left. The codebase contains a lot of good ideas that have been implemented very poorly or in an obviously half-hearted manner. For example:
- Inversion of Control is in use (which is a good thing) but it’s using a horrible mixture of XML-based component registration, fluent registration and convention-based registration. There is also a mixture of constructor injection, automagic field injection and service location.
- Separation of concerns has been attempted and you can see that the person who did it had heard of DDD and liked the idea of it, but it looks as if that person completely misunderstood what a bounded context was. Instead of having a nice domain layer with business and value objects, domain and application services, we instead have somewhere around fifty different solutions (yes, solutions, some of which contain only one or two projects) that each have their own data access layer and entities that are all so tightly coupled they should never have been separated in the first place. It’s incredibly frustrating to always have to have four or five solutions open at once to develop a simple feature: debugging is a nightmare and large-scale refactoring is more or less impossible. Oh, and of all those projects from different solutions? When build they dump their own binaries into a god-like references folder in the root of the repository and everything references everything else.
- The main architect of the solution has displayed one of the most egregious cases of fear of the “not invented here” I’ve ever seen. Rather than using documented, reliable, tested and supported software from the community he has written his own:
- mocking framework
- caching layer. This uses Castle Windsor to provide proxies of command objects at runtime that retrieve their results from a cache if possible. MSMQ and NServiceBus (a horrifically old version) are used to send cache invalidation messages between the load balanced servers
- wrapper around the Castle Windsor container for dependency injection
- a Razor viewengine (basically for providing his own implementation of display modes…)
- a “RunTimeOptimiser” that essentially just bundles CSS and Javascript
- the list goes on. Seriously.
- Tons of code is either unused or does nothing, or references twenty binaries that it doesn’t need
- Unit tests are almost non-existent and UI tests are extremely out of date and have patchy coverage
- Todo items and commented-out code throughout the solutions
- There’s no use of NuGet; DLLs are checked into source control (in the central references folder mentioned earlier) and are then copied from project to project using the manually-written build scripts. Our build packages are hundreds of megabytes in size – a size that has been reduced to around 40 megabytes with our recent experiments at sorting out the references, dependencies and project structure.
Phew, glad to blow off some steam there. There are some big changes being made on the code front, so we hope to be improving on all this very soon.
Our team is just one Scrum team in a department of something like 250 developers. Yes, we’re a big software house. We are the only team working on our particular product: ASOS Marketplace. The team is incredibly new: in the run up to Christmas it hit us that, out of four devs, two QAs, two front-end devs, one project manager and one business analyst, only one of us was here last Christmas. Four of us are still in probation!
Overall I’m really looking forward to my time here at ASOS. There are plenty of fixes to be made to the codebase (you will not be surprised to hear that the custom solutions outlined above have left us with some serious performance problems), but I relish the challenge and we now have the political freedom here to make changes if we feel that they are necessary.
I’ll check in soon with more updates, probably in the new year.