Prototyping vs. doing ‘real’ developement
I’m currently making a prototype where I have to show how the final application will look. That means, I have to build basically everything, I would normally build for the ‘real’ application (data, styling and command-logic). This is not my preferred way of working – normally I would build it incrementally – one functionality at a time and then at some point introduce styling – but I understand the reasoning. We need the marketing material some time before we have a working product. And we need early feedback to ensure that we get qualified feedback as fast as possible.
At first, I tried going about it, as I would with ‘throw-away’-code – heavy code-behinds – direct instantiating everything in Resources-tags and generally introducing messes all over the place. This worked well for about two days. At this time, I sat down and looked at the mess… and realized a few things.
Motivation wasn’t there
I actually lost a lot of motivation going about coding something I knew was going to be thrown away. Just looking at horrible code was enough to make me go… “Arhh… I’ll work on it tomorrow”. Having practised heavy re-factorings for 2 years has made me appreciate elegant code – and my fingers were itching at re-factoring this horrible mess. (And when I say horrible mess – I’m not sure how other developers would characterize it, but it’s certainly a lot under my normal quality).
Coding speed was actually slower
This may seem counter-intuitive, but it is actually true. Using ReSharper, I crank out code which uphold most of of the SOLID principles without needing re-factorings since I’m actually coding stuff, I’ve tried before. I have a fairly good idea when it’s time to introduce a base-class and which responsibilities go where. And having no IoC container to handle the wire-up – I was writing a lot of code just to get my buttons to do something. Also, using WPF – a lot of styling is relying on common interfaces and TemplateSelectors on top of ViewModels – and that is extremely fast compared to rolling XAML to e.g. hand-craft a toolbar. Also, I spend a fair amount of time in the debugger, because I made rookie binding errors.
Friction was at an all time high
Adding the first 2-3 features went fast, the next 2-3 went okay and then it started grinding to a halt. It was a bit of an eye-opener how much friction is reduced by using good OO-practises and coding to SOLID. Normally in production code, adding a feature is a matter of adding an interface – and not changing or replacing an existing one. In the prototype this was just not true – I continually had to rewrite a bit of functionality to take into account this new situation.
So, the solution has been to do production code instead, albeit with a slightly tweaked production method. I call it scaffolding code. First, I created all the modules, we have on the drawing board and introduced a few buttons here and there. Then came a styling round to make it pretty. Then I added one of the main screens with domain objects that are pretty much stupid DTO’s. Again, styling. Next a new main screen… styling – you get the picture. This means that all data-access is in-memory, validation is non-existent and a lot of functionality is represented by a button alone.
So far, I have two ‘working’ screens and about 5 ViewModels that are pretty much doing what they will be doing come live-time. I have ‘real-looking’ data to simulate what it will look like in production – and I’m blazing through functionality. And as my base-classes are starting to pay off – each new feature is actually faster than the first few features. So, I’m picking up speed (eventually, it will plateau, but that’s okay).
It’s funny how sensitive, I’ve become when it comes to building it ‘right’. Some features are cheating a bit – some edge-cases are missing from the selectors and so on, but overall I’m getting pretty excited about this project! It seems I’ve hit a structure that will be there for the long haul.