As I look back on my formative career and the moments that contributed to the approach we take at Retail247, I’m reminded of the development project we did for the first automated sales forecasting tool, WSSI, at Debenhams. This was in the early to mid-nineties. For our younger readers I’d like to point out that there was nothing wrong with DOS. However, I am skipping past seeing punch cards being delivered to the enormous computer room for compilation and, more often than not, rejection.
Our brief was to write a professional solution to deliver a WSSI across all Debenhams departments; we were given complete freedom in terms of technology and approach. Our ‘bitter rivals’ at Arcadia, the other half of The Burton Group at the time, had opted to develop their solution on the AS/400, the fools. But we knew better; we would develop ours on a PC architecture and make a far better application!
We were developing in Clipper, a DBase derivative (how we chose that is a story for another time) and the use of the database servers and client server architecture was just emerging.
I believe there was a spec but, as we all know, they are only for guidance. We trail blazed based on what the technology would allow us to do and what we knew would be best for the user. I invented whole new functional areas that nobody had asked for, but that everybody loved. These were fun times. It’s worth mentioning that I was an Analyst/Programmer, and as such, was expected to design, develop and test whilst understanding the context of the requirement and how it applied to retail. We were the custodians of the overall process and it worked well.
I concentrated most of the development effort on the ‘Client’ side. We embraced Object Orientation, dynamically compiled code blocks and whatever else we could find in the instruction book (none of that Google stuff back then!). We tackled many areas head on, deploying approaches that are still valid today.
However, we hit a problem. We were running out of DOS memory (the 640k, less the DOS kernel, barrier was what we had to work with back in the day). We ended up fully deploying the radically new IBMOS/2 Operating System to all desktops, just so we could have the full 640k and enjoy just a little bit more operating space.
We weren’t satisfied with the performance of overnight processing. Again, don’t forget PC power was limited in those days and servers and SQL Server licensing were disproportionally expensive (they may still be!). I remembered I’d seen something on television about NASA using global distributed processing when people had downtime on their PCs. It seemed like a good idea, so within a few days we had all the PCs pulling WSSI ‘cards’ locally overnight, performing various calculations, then posting back to the server. I’d be prepared to bet that this was the first use of distributed computing in retail!
The actual re-calculation of the WSSI on the PC when the user pressed calc, F9 I believe, was given an arbitrary target of 9 seconds. I vividly remember working with the BA, sat in a hotel café, until we got it done. No spec, just innovative trial and error (or sprints as we call them nowadays).
This was the first multi-user PC solution we had developed, so testing was a challenge. Multi-user testing was done by three of us on the Buying floor after hours, coordinating our button pressing: “1-2-3 go” could be heard for a good few hours (well, 30 minutes at least).
Because we had autonomy and were allowed to innovate, innovation flourished. For example, we deployed automated fault logging. If the system crashed the error handler logged a fault with the help desk, which included a screen shot of what the user was doing at the time. We often investigated, fixed and re-deployed before the user had a chance to log a call. We were not afraid to deploy frequently and regularly.
Now obviously the world has become a more complicated place and coding must address many unthought of scenarios, but a lot of the philosophy is still valid. The solution I’ve described was ground breaking. It was liked by the users and was used by Debenhams until relatively recently. It represented significant value.
Innovation is fluid: There is usually a better, or at least alternative, way of doing something and if you don’t explore this, you could be missing an opportunity. Having confidence in the core data you are building the system for also makes obvious sense and is the approach we are taking with the Retail247 core foundation ‘engines’.
So, in summary, get things done, don’t be afraid of change and don’t be afraid to innovate and challenge. It often brings the best results.
With thanks to David Callow who got to grips with early releases of SQL Server to sort the back end out, to Giles Walker who understood all the data stuff and made me do the calculation in 9 seconds, and to Khalid Taha who wrote some reports with the forecast data that I still don’t understand to this day; good times gentlemen.