No Design? - Your Code is Junk
Twice in the past week I’ve been told variations on the same story. It goes like this. Smart guys want to build killer internet app. Smart guys hire a bunch of programmers who have drunk the magic agile potion. Programmers get started on ‘self-organization’, by which they understand this to mean that they can do what they want to do. So one guy wants to do Ruby, another guy PHP and a third guy Java. Why? Because they want to try something out in a real company environment and not in their bedroom. Why? Because they’ve got one eye on the project, and one eye on their CV (resume). When they find something really cool, they go to the CTO and say ‘hey, can we do this really cool thing?’ He never asks why. He knows developers are hard to find. Better keep them happy, so he says ‘OK - go ahead. Great job’.
They deliver something that works. They deploy it. It starts to run really slow. The devs blame the users - it worked fine when there weren’t any.
The marketing and product guys want to open up a new market, except they can’t. What they deployed is junk. It’s a working prototype, it’s not production code. When they ask for some new functional behavior, the team won’t accept it - they keep talking about ‘technical debt’, and ‘refactoring’.
So, eventually the owners of the company get frustrated enough they fire the CTO and get a new guy in. Now the developers come to him and say ‘...can we try this really cool thing?’ and he says ‘why?’ They don’t know what to say to that. So, they start complaining and go to the CEO and say ‘we can’t work with this new guy. He’s got to go. It’s either him or us.’ And guess what? The CEO accepts their resignations and starts looking for some new devs who are going to self-organize around the company’s goals and not their own personal goals.
Here’s the thing. BOMs, OOD, and entity models are ‘old school’, in the same way that Plato is old school. If you don’t understand something, that doesn’t mean it’s no good, it just means you don’t understand it. If you don’t put some effort into the design of what you’re building, it might work for a while, but it won’t be production code - it’s a deployed prototype and it’s going to come back and bite you in the bum.
If you can’t write object code, then you’re writing junk. And you can’t write object code without a model, because it won’t just emerge. It just won’t.
So, now these guys got some old school people to build it right. It’ll take a couple weeks to get the DESIGN done, and then it will go just as fast as hacking it, if not faster, and in the end it will scale. Then the marketing and product guys can have all the new functional behavior they want, and nobody will talk about ‘refactoring’ - which is just another way of saying your hack went live.
So, you are imagining a team that does not understand agile at all, and using that as an example of what is wrong with agile development? You have no scrum master involved in the development. You have no product owner involved in the development, prioritizing the functional requirements and communicating the user vision to the developers. More than that, you have no senior people involved in the development. And you contrast that disaster to a theoretical situation where magically, your senior designers come up with a correct initial design in a few weeks without going into the details of the entire implementation? Sure. I could write the exact same thing with the same inexperienced developers as a waterfall project, and it would end the same way. In fact, the standard answer from a waterfall organization to those marketing people is, sure, once you cost-justify it, we can design that features into the next release or the one after it. We'll have it for you in early 2016. Give a competent agile team with stable personnel and six months of funding, they will have fixed their technical debt and deployed three to five chunks of valuable user features.
I know from my own experience that management often does not know the difference between a POC and production code. I once was asked to make a POC in 9 days, so I made it quick and dirty to get it done, I said at every step it was not production ready. They loved it and wanted to go to prod immediately, I explained a POC is like a rough draft and not ready to be published. My manager ended up writing me up for not taking the assignment seriously.
Jane Prusakova Yes, that's right. I agree with that. The point is, that when they proved it, they had to design it. We have two kinds of models. Analysis models - fine and easy enough to do even for crappy prototypes and Design models when you need architecture etc. so the thing scales. I think it's ok to build and deploy weak code, the only problem is getting stuffed when it's successful. If it tanks, it's good the extra effort was done. But this is an argument for design models, not analysis models. I think the conclusion is defensible. It's more interesting that it provides some controversy.
It's a great story, but it does not match the conclusion. They decided to build "a killer app", hired some cheapo devs, hurried them up, and got a barely-working prototype - quickly. Learned from the experience, went back on the market, and hired better people, probably for more $$$, since now they have some idea how devs fail and what to screen for. And, viola, better team built a better product, using the learnings from the earlier iteration. Would it have worked just as well if they started with an extensive (and expensive) planning phase, without any prior experience of building a failing prototype? Was the original team really terrible, or were they faced with badly set up expectations? Blame only gets us so far. Models and better code emerge from understanding, and understanding emerges from trying. Ivory tower models fail, and so does jumping into coding. Iterating approach works.
Hi Stephan Roth. I'm grateful for this distinction that a user story is not a requirement - it's a planning unit. That's smart and helpful. Do you agree with the distinction between requirements models and design models (or analysis and design if you prefer). I'd like to understand what allows a language like Erlang to handle 60 billion (?) messages/day. I've not heard of the language to be honest. Do you remember the old idea of the Capability Maturity index? Is that still used? I was always a little dubious, but the idea of maturity is sound. A mature org would select the technology based on the task to hand. Still, Whatsapp could have had no idea in the beginning they would handle such volume. The question then becomes 'did they re-write it when they found out?' I also wonder where they found the developers with the Erlang skills. And yet again, I also know it is not so hard for a talented/classically trained C programmer (for instance) to switch into a new language. I thank you for your intelligent contribution.