When starting a new project, my boss always avoids to make fixed decisions. He is usually saying: ok, just start to write something and be as generic as possible. When you're finished we look how we continue. His argument is basically that you never know and "agile development".

To keep the question as generic as possible: what do you do if your boss doesn't like to make decisions?

Just stick to it and write code that might undergo heavy refactoring and partial rewriting a few weeks later? Or keep on discussing until the boss does at least a few decisions? This is more or less my current strategy. Because it's like a law of physics, at some point something needs to be delivered. Either because the boss' boss wants to see results or because stuff is becoming ridiculous at some point.

I also observe that my boss is criticizing nearly everything. Even suggestions that are based on his own...

  • 1
    Per SICP lectures, start writing code in LISP :)
    – Job
    Oct 4, 2011 at 21:26
  • @Job - Is LISP designed for this workflow? ;)
    – Jimbo
    Oct 4, 2011 at 21:58
  • Lisp (but I would actually recommend Clojure) allows one to make drastic changes to the design. When used properly, it allows to build layers upon layers of abstraction and change one's mind, add features, etc. paulgraham.com/avg.html
    – Job
    Oct 4, 2011 at 22:10

8 Answers 8


Build prototypes

Just start drawing screens that don't do anything at first (presumably you have enough to do that?)

You should be able to make it partially functional slowly, and eventually refactor some of the bad code when it becomes more clear what you are trying to do.

It's a common problem that they don't know what they want until they see something and realize that's not what they want. I've found that when someone wants you to just start building 'a framework' or something 'generic' like what he is telling you, you are just going to get in trouble if you try. The frameworks are already written, you don't need to do that.

  • This sound really familiar: 'a framework'. Probably I should wait to set things into stone after showing at least two or three demos/prototypes.
    – Jimbo
    Oct 4, 2011 at 21:38
  • 5
    +1 Nobody knows what they want. Everyone knows what they don't want. Criticism is easy to get and can be informative.
    – JohnFx
    Oct 5, 2011 at 1:23

There are several issues that I have gathered from your message: 0-It is not your job to manage the project and it is not your job to gather end-user requirements. 1-The boss does not know the exact requirements 2-The boss does not to talk to end-users about the requirements 3-The boss is throwing terminology he does not really understand agile 4-You are working out some solution that gets re-written several times and you are not happy about it

As for 1,2 and 3 there is little can be done about this if you are not a senior person. However, the following can be done:

A - Ask him to share with you the project plan. He may have one or will build one showing the tasks and deadlines. One of these should be about analysis and requirements gathering. If not suggest it.

B - Prepare some references on the importance of requirements to the success of software project

C - Prepare him a 1 page of what Agile is and is not.

D - Prepare him a list of typical inputs to the design stage and convince him of the value of each.

E - Suggest the addition of a business analyst and/or data modeler to the team. Such roles will have to sit with the end-user and will get you the information required or at least good part of it.

F - See how other developers cooped with this guy.

As for #4, you can suggest to him to use a prototyping approach or a code generator that would help him, you and the user to make their mind about the functional aspects of the application. Most tools don't generate perfect GUI, but at least you could capture the functionality required.

In all cases, make sure that you document each of the iterations clearly and send him an email about what input you have received, what you did (in some detail) and what the outcome is. Make sure you attribute the outcomes to the proper cause such as (lack of requirements, etc.).

Unfortunately some people don't accept advice. So be careful how you communicate with him.

This is not going well!

Good luck.

  • Thanks for your detailled answer! My current position is in between junior and senior, at least that's how I described myself during the A: He has none is not interested in any, empirical insight. B, C: Not now ;-) At least about the current project he knows a lot about the day to day problems. E is a nice idea. Today I wrote a small demo, we were discussing it a lot today. Though I was amazed about how many points he was unsatisfied. Can you please explain what you mean with D?
    – Jimbo
    Oct 4, 2011 at 21:34
  • Design requires inputs. For example, Data Model (created at analysis), Business Rules, Security Requirements, Use Cases, Essential Architecture (is it a web, windows forms, or what). The inputs differ by mehtodology name, however, they all lead to make the developer aware of what the design should be like.
    – NoChance
    Oct 4, 2011 at 21:43

I used to have a boss like that - in fact I would joke that his motto was "indecision is the key to flexibility".

Whatever development work you do, you're probably in a better position to solve the client's problem than your boss. If you don't know what the problem is the client is trying to solve (which is not the same thing as a spec), then someone is not doing their requirements gathering properly.

Sketch some page layouts, or build a non/semi-functional prototype. But do something. It's not clear from your post whether you're building full-client software or web-apps, but the beauty of the latter is you can release-early, release-often. Start with the bare-bones and work it up from there. A false start does no harm if it gets some dialogue flowing and some decisions made.

We have a saying around $WORK (internal web-apps) for our clients: "I'll give you something so you can tell me what you want." Be prepared to throw the first draft away, but you might be surprised how rarely you actually have to.


Point out to him that the Agile books suggest postponing decisions as long as you can but no more than that. Every decision has a point where it has to be made, and maybe you're there right now.

On the other hand, also question yourself. Do you really need to decide what persistence layer you're going to use for this app? Or can you start off writing it to a CSV and keep it abstracted enough to make that decision later?

  • The technical decisions are more or less clear to me: programming languages, how to choose libraries or persistence layers. He has strong opinions on that, and to be honest, I really don't care if those choices are sane. It's more about things like: what will the screen look like? What kind of things will the user be able to do and how? I already figured that it's a lot of my job to come up with ideas. But it's hardly possible to propose abstract ideas and ask him whether he is ok with one idea.
    – Jimbo
    Oct 4, 2011 at 21:46

Write your own spec document and hold a review where you explain it and he signs off on it. Then you will become boss, and your boss will move into more interpersonal management issues rather than technical issues.


Engage in 'upward management' talk to your boss and clients, figure out some solutions, pick the best one for your team to implement, find flaws in the other ones, and 'manage' your manager into making the 'right' decision.

And of course make sure he thinks it was all his/her idea. (especially when it all goes wrong!)

  • When software engineers turn social engineers.. :)
    – MattDavey
    Oct 5, 2011 at 8:53
  • 1
    Seriously, most software problems are solvable, its the communication with other semi-sentient bags of water that is often the problematic bit...
    – user25446
    Oct 5, 2011 at 9:51

You need to design and implement something. Since your boss won't make decisions then make them yourself. Take a little extra time to document your decisions and assumptions before you implement them. Send it to whoever it may concern including your boss. Hopefully, that list includes more than your boss as it will put a little pressure on him to make some decisions since he knows that others are aware that you are ready to proceed. You will be surprised at how quickly you get feedback when you put decisions in writing, especially if you make decisions that other people disagree with. In the meantime, I would proceed with the decisions you made until told otherwise.

If you ended wasting time implementing what your boss didn't want, then it is on him and not you since he was aware of the path you were going to take.

Also, some people have a difficult time getting started, but once they see something tangible then their mind kicks in. Maybe your boss is like that and your telling him what you plan on doing in writing will get his mind going.


Make decisions yourself and start coding. Of course, developing in a flexible way will help (read Robert C Martin's Agile Patterns, Principles and Practices if you haven't already) but all the flexibility in the world won't help if no decisions are ever made. You may find you have to just develop what you think is needed, and then modifying it as required. Often clients/bosses don't know what they want until they see it, or until they see something they don't want. This will probably take you outside the scope of being a developer, but that's life. I often find that I and my colleagues are effectively making business descisions. Sometimes these aren't questioned, and decisions I've made start driving the business, purely because no one else would make the decsision. Be sure to list ALL of you assumptions and decisions (no exceptions) and present these to your boss.

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.