How should I weigh the cost of rapidly testing for customer signal versus proper upfront design?

Question

I have two engineers with very different development styles.

Engineer A prefers a high degree of upfront planning and designing, considerations for all possible options with pros/cons mapped out. Engineer B prefers to find the quickest path to test.

We are a skunkworks team and are responsible for testing a bunch of new ideas. So Engineer B seems to be taking the right path. On the other hand, the rationale from Engineer A is, if something works, we would have to toss much of what we've just done and build it "right." So a "go slow to go fast" mentality.

I am frantically trying to hire a technical leader for this team, but in the mean time I'm in charge and my lack of technical background is starting to show. Any advice, or even pointing me in the right direction would be helpful!

Answer 1

There's obviously a sliding scale in these things, but my number one advice for you is to stop using emotionally loaded terms like 'proper planning' or 'fast vs slow'.

Just be clear on the technical requirements and that there are no hidden unstated requirements. (easier said than done)

This allows the developer to assess whether they are skipping out on features to go fast, or putting in extra features that wouldn't be missed.

Secondly, be clear on the strategic goals of the team. I.e. get 10 demo projects finished by quarter 3 or whatever.

This will give the developers a way of judging how much time they should put into each individual project.

Thirdly. Take your customer into account. Some people hate seeing incomplete products "of course I want it to be fully styled according to my company design guide! Show me when it's finished!" and some hate being asked for requirements up front: "I can't tell you where I want the button until I see it, just show me something and I'll tell you more."

Answer 2

We are ... responsible for testing a bunch of new ideas.

Then you need to focus on the Minimum Viable Product. Fundamentally, I agree with B: getting early feedback and iterating is going to give you a stronger resulting product, from the users' perspective. That doesn't mean shoddy engineering, but it does mean leaning heavily on YAGNI, and certainly means that spending a lot of time on up-front design is a bad idea. A is likely to find this frustrating at first, but hopefully as they see the product grow to fit the users they will see the value.

Look at it this way: A is worried you'll have to re-work things. But whichever path you follow you will end up rebuilding stuff, because it was unpopular with the users or a new requirement incompatible with the previous approach came up. If you've spent weeks designing the perfect solution to the old problem this is hugely frustrating; if you've only spent days on it, not so much. The Pragmatic Programmer talks about tracer bullets, getting live feedback on how close you are to the target (particularly valuable with a moving target, or one where you aren't yet sure where it is).

Also think about what happens to anything that becomes successful. If you're the skunkworks, and something proves useful, does it get taken out of your hands and given to someone else? Are you actually providing value to the broader organisation by creating a polished product, or would everyone be better off if your team demonstrated the core value of the product and let the team that takes it on build on it or reengineer as they see fit? They may be happier with a bunch of useful customer information, a working prototype and some end to end tests around the core features that they can reuse when rebuilding it their way.

---

So what can you do about it? Firstly, be clear on what the team's goals are, how success of the team and their products will be measured. If you've got a lot of new ideas to try out with a small team and short timescales, you cannot make everything perfectly (if you can even figure out what "perfectly" is, but that's a whole other answer), so be clear about whether they should prioritise building fewer to a higher standard or more to a lower one. Help them make the technical decisions you can't by providing them a framework in which to measure and compare the outcomes.

Secondly encourage the two of them to collaborate closely, or even pair program. I've found pairing with other engineers with different tendencies to be a good way to find a positive balance between our strengths and weaknesses; B can encourage A to see the value in early feedback and discourage their tendencies to gold plate, while A can use their inclination to thinking about the bigger picture to head off any "dead end" decisions that will work against the team's ability to keep developing the app as new requirements come in.

Answer 3

As a big proponent of upfront Architecture and Design, I have to reluctantly agree that Engineer B is correct in this specific scenario.

Your team sounds as if its primary responsibility is to not build a highly specific product however you sound more like an incubator of future products by developing prototypes. In your specific circumstances it is better to focus on building a prototype and handing it off to another team for refinement into a proper product. I would argue at that time a proper Architecture and upfront design should be done, and this will help you identify important technical non-functional requirements of your System Qualities.

The other team may find that the appropriate path is refactoring large parts of the prototype however this is to be expected. Rework can sometimes be far less expensive than being late to market or production. Look at the early days of Twitter. It was essentially rapidly developed with little upfront design using RAD techniques with Ruby technologies. When Twitter became popular then this quickly did not scale, so large portions were rewritten in Java.

With all of that being said, even with upfront Design, one should keep in mind that design artifacts are only useful as a means of communicating or conveying a technical idea. A really good book on the subject of how much Architecture is enough can be found here... Just Enough Software Architecture, A Risk Driven Approach.

Answer 4

Make them work it out.

If they're coming to you to break a tie on a difference of opinion don't pretend you know better when you don't. If something strikes you as wrong don't say so unless you can clearly explain why. Don't vote when you don't know. If you can contribute knowledge then fine. If they're unwilling to reach a balanced compromise then the ultimate authority in a tie is a coin.