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!

  • 6
    They're both right. These two will balance each other out very well if they can learn to compromise.
    – RubberDuck
    Commented Apr 16, 2017 at 0:48
  • 6
    As much as I want to say that both sides can work, I have yet to find any evidence that Big Design Up Front actually makes the design better. Again and again it is realized that no amount of thinking and predicting beats actually building the product.
    – Euphoric
    Commented Apr 16, 2017 at 9:04
  • 1
    @Euphoric That is highly dependent on the product being built and the necessary technical complexity of such a product. If you look at what a design artifact represents it is essentially a communication tool for a series of related technical ideas. If your team is composed of rockstars, then this is less important because there is so little overhead in communicating complex technical and architectural details to skilled people. If your team is mediocre or inexperienced then I have seen where technical communication suffers and would have benefited greatly from more upfront design.
    – maple_shaft
    Commented Apr 17, 2017 at 11:47
  • 1
    @Euphoric Perhaps you are right, however there are many tasks that developer can perform without requiring context. And as far as evaluating correctness, I don't know why you would expect everybody writing code on a project to be a full software engineer and not just a run of the mill programmer.
    – maple_shaft
    Commented Apr 17, 2017 at 14:45
  • 1
    @maple_shaft I'm mostly focusing on the process of design itself, not on the final artifact. Which seems to be the main question here. It is true that final "design artifact" is about communication, the process of design is something completely different. I think we should be more clear if we are talking about the "design artifact" or "process of design".
    – Euphoric
    Commented Apr 17, 2017 at 14:54

4 Answers 4


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."

  • This is helpful. Would your response change if our team were not skunkworks and starting to scale a product? So let's say in the future, we hit on something and we are planning to add new features to it. This same argument will come up as Engineer B will want to move as quickly as possible to test the new feature, while A will want to make sure the new feature aligns with the current product's design. Commented Apr 16, 2017 at 15:39
  • 1
    @user3075512 with the team as with the product: YAGNI. Maybe it will be given to someone else and you'll continue testing new ideas. Maybe the team will be reorganised to bring in different skills for the scaling phase. Focus on solving the problems with your current team and their current objectives.
    – jonrsharpe
    Commented Apr 16, 2017 at 16:09
  • no. because the A or B approach is determined by the requirements of the project/customer. if you are just creating proof of concept work, you should have different requirements to production code. If you want the code to align with an overall design, that should be specified in the requirements. 'code must be documented and maintainable for 5 year expected lifespan with scope to extend in ways X and Y' for example. If not you should write 'product is purely proof of concept demo. no need for scaleablity or performance in any feature. only code happy paths X Y and Z'
    – Ewan
    Commented Apr 16, 2017 at 16:15
  • Once you start to write these things down, youll probably find that you have the same problem as the developers. ie, its not totally clear whether a project is purely a demo or not. maybe its a demo today but if they like it they will expect it to be live tmrw. You will be forced to push that question up the chain untill someone signs off on 'yes its just a demo' or 'no this has to be ready to go live if we like it'
    – Ewan
    Commented Apr 16, 2017 at 16:25

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.

  • Thanks, you're right about having clearer team goals! Also, one thing I'm thinking about is, we assume both engineers are equally capable, just different in approach. If they aren't should this impact my decisions? For instance, Engineer A has proven himself and has consistently completed work on time, with high quality. Engineer B is relatively new, has proven himself to work really fast--but draws the ire of Engineer A for having messy code or "just doing what he wants" which could impact Engineer A's design and plan for the product. Commented Apr 16, 2017 at 15:47
  • @user3075512 I had assumed the difference was primarily in approach, but it's still possible they can learn from one another through collaboration. A may be capable of good work but if they're wedded to a "big design up front" model of development they can negatively impact the team's ability to generate and respond to feedback - they want to do it "right" but it's often unclear what right is. Perhaps B can be encouraged to improve e.g. their code style and structure, but if they are really doing what they want rather than what the team has agreed then that is a problem.
    – jonrsharpe
    Commented Apr 16, 2017 at 16:00

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.


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.

  • Why should B jeopardize his obvious value to this skunk works team by following waterfall-ish practices that have clearly demonstrated their inferiority all over the world? And what shall B do if the coin turns against him? He shall leave the company and abandon the OP in the hands of a stubborn perfectionist. What a poor advice you're giving! I wish I could downvote you ten times. Commented Apr 25, 2017 at 6:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.