I can't tell you how many times I've run into situations where a higher-up says 'Look, just do it'. This is obviously at the expense of rigidity in the planning process, and will (probably) affect product quality.
By now, I have more experience with this, and with that, I have the confidence to stand up for the quality of the applications we produce here.
How would you handle this problem?
Is anyone out there a manager who's used the just do it command on a programmer? Why?
I find it's very important to be able to estimate completion times for tasks. If a manager gives you a crazy task, be able to tell him in a relatively short amount of time a realistic expectation for the amount of time it will take to complete their dream task. At least this way the manager can decide how important it is to him/her to get their task done.
Typically I have a good working relationship with managers. What I usually try to do is given them trade-offs: "I could do that but then...If I did this instead...", then I let them make the decision. I once designed a de-normalized database -- completely flat table structure for each type of query -- because the boss's boss asked me to. I was 1 month on the job and I knew, because my boss shared the history of the project with me beforehand, that I likely wouldn't be able to convince him to do it otherwise. He just hated joins of all kinds. Now that boss is gone and I have a project in my backlog to rework the original database to add some extensions and I'll normalize it as I refactor. Now that I've been here longer, I'm more likely than not to be taken up on the alternatives that I offer partly because I've genuinely left the decisions to the person paying the bills when that person cares.
Some of these problems are caused by bad specifications.
However you also need to consider does the manager actually know best? (yes it can happen sometimes!) they may be privy to some info you do not have.
Ultimatly if you have to deal with this all the time you may want to look for another position.
Take a look at this book it discusses the politics in detail: http://www.amazon.co.uk/Career-Programmer-Guerilla-Tactics-Imperfect/dp/1590596242/ref=sr_1_2?ie=UTF8&s=books&qid=1223055601&sr=8-2
Whatever you propose to your boss, make sure that it looks good in Powerpoint. If it looks good in Powerpoint, chances are that he (or she) will go for it.
I make sure to document the requirements from that boss, complete the code and document it, and put in writing "suggestion" on how to improve the process. I put these suggestions in the code comments, in the documentation, and in the one page spec I usually write.
Most of my "just do it" jobs were because the boss wanted X to happen and couldn't be bothered to do any planning. So I covered my ass by writing down my objections on all the paperwork, but kept my job (and my paycheck) by "just doing it"
I don't work there anymore, and that company will never be as big or successful in projects as the place I am at now. The lack of process and the "just do it" mentality are signs of a small company. I handled it by moving on to a new outfit to progress my career.
Take a 'how to sell' class, or read Selling for Dummies, seriously though, is all about how you present the solution and SELL the idea that you want them to BUY. I did sales for a while before being a full time software engineer and I can really see the value of the stuff I learned there.
The most likely cause of being told "look just do it" by a superior is information asymmetry: either of you or both of you know something that other party doesn't. The manager might not be telling you that in the grand scheme of issues this specific problem is fairly unimportant or they just looking for a quick fix, since there is much pressure from someone else to get the thing done quickly or they simply might plan not to stick around long enough to take responsibility for the consequences.
In a similar manner they might not be able to fully appreciate the risks associated with the adverse choice, may be deliberately making “wrong” pick since it helps them to meet their personal goals etc. Information asymmetry http://en.wikipedia.org/wiki/Information_asymmetry is a well known concept in the field of economics and you might want to read up on the topic.
The most likely cause, however, is a looming deadline, lack of planning and hence the total absence of time for any manoeuvres.
Solutions are many. There are two that worked for me best:
a) Improve communication; communicate more often and more efficiently. This means listening more, trying to understand whether the problem is lack of understanding of the risks associated with the poor quality, lack of appreciation of the software quality and adverse effects of taking shortcuts on the future maintainability (it staggers me that often it is the same people who would buy only best quality very expensive cars and insist on taking shortcuts in building software, highlighting the difference in how personal and non-personal choices are treated).
Or the issue might be that whilst actually fully appreciating the value of software quality and understanding the impact of future system maintainability (in my personal experience this is less common) they make a conscious decision to go down a cheaper route.
In essence, communication here means not that much trying to actively sell what you've got on your mind, but to try and absorb as much information as possible from the environment and the manager. Then it is going to be much easier to figure out your next step.
b) Alliances and partnerships. It is impossible to overstate the value of alliances. Even when your manager or project sponsor does not provide adequate support for quality (which is part of their job) a right alliance can help improve things significantly. Find these who care and unite. It can be a project sponsor who cares, when project manager doesn't, or it can be project manager when team mates don't. It can be quality manager, a director, a fellow developer or business analyst or tester. The bad guys will back out or leave you alone to do the things right and then will definitely jump on the boat to collect the credits. Look at politicians, when they trying to achieve something first thing the do is forming a coalition. Unfortunately, when you told to “just get on with it” you’re already involved in politics whether you like the smell of it or not.
Find someone who has a significant stake in the project’s success or failure, in its quality and make them an ally.