Manager keeps changing requirement specification after every demo.

Question

Background of my working environment

My manager has no background or understanding of computers or software whatsoever. It is highly likely he hasn't seen code in any form (not even from a physical distance of 10 feet or less) in his life.

There is no one who understands the complexity of what I am asked to implement. To the point that if I semi-hardcode no one would know.

On Joel's test we score an unbelievable score 0.

The problems

• The manager and at times other "senior" keep changing the requirement specification. Changes which, if good engineering be done and not patchy "fixes", require change in the underlying design.
• There is absolutely no one who looks at code (probably because no one knows how to, or even if it should be done) which means no one will ever be able to:
  • Appreciate the complexity of the problem or the elegance of the solution.
  • Suggest improvement to the approach.
  • Appreciate the quality of the code.
  • Point out where the code can be improved.
• A lot of jargon is used which makes sense grammatically but fails to make any sense any other way.
• Doesn't feel, behave or work like a software company.

The question

What should be done? Especially regarding there being no one who would point out improvements in my code.

Update

To answer HLGEM's (and possibly others) question about what I've done to try and fix it. I offered to set up Redmine and introduce source control to everyone. I said I would recommend distributed (git or mercurial) but will also talk about centralized ones and let the team decide. Response was that things are being done and will be done within weeks. Haven't seen that nor am I aware if other parts of the company use it.

Answer 1

The short version:

Run.

---

The somewhat longer version:

If the manager doesn't know how to run a project, and if the senior goes along with it, then you have next to no chance of fixing things.

In order to manage software projects, a manager does need to understand something about software. If managers don't, they need to learn first. What are your chances you could persuade your management and your senior(s) that they got it all wrong? What are the chances you will teach them something?

I have been in a similar situation once (only there was no senior). I quit after a terrible year, and never looked back (except in disgust).

Answer 2

You say in one of the comments that this is your first job. Managers often aren't technical anywhere except a dedicated software shop in my experience. This is part of life, just get used to that.

You cry and whine because there is no one to appreciate the elegance of your solutions. The real problem here isn't that there is no one to appreciate the elegance of your solutions, but that there is no one to teach you that your solutions aren't nearly as good as you think they are. Virtually all new programmers overestimate their actual skills. With no mentor, there is no one to help you to better practices. If there is no one there to mentor you, then join local user groups, actively participate, and get someone there to mentor you. Even better, that will help you find a better job eventually.

You score a zero on the Joel test? If you are the only coder (and it sounds from what you wrote that you are) they why aren't you using source control? What is preventing you? If you aren't the only coder, why is there no one who can do code reviews? All our devs do code review, it isn't a management function especially when the managers are non-technical.

Requirements change in pretty much all places. Business needs change continually and non-programmers often can't visualize what the program will do until they ee something. Then they realize it isn't what they need. That's why Agile came into being really because the older methods were not handling that change well.

Set up bug tracking even if the management doesn't want to enter the data themselves. Be responsible for entering new bug/features as someone mentions them to you. It really helps to be able to tell the manager when he wants a change that you have been assigned 27 other things and here is the list, which one do you want me to move down the priority list to accomodate this new change. It will help at review time because you will be able to count up the number of bug fixes and features you implemented. If everyone isn't using it, then at least you can for your own work. If they won't let you install any software then use an Excel spreadsheet. Take some initiative. Once you can show results, others will be more interested. If you think there is too much work for one person, the bug tracker will help you prove it.

Do not provde polished looking demos! Demos should look as if they are scribbled in pen on a piece of paper. The more polished the interface looks the more the non-technical person thinks it is finished.

Even though no one would know if you don't follow best practices and semi_hard code for instance, you will know and you will get into sloppy, bad habits. That will not serve you well in your next job. So do things as close to the right way that you possibly can under the circumstances. Make sure to write tests (just consider this as part of the development time and put the time to do it in any estimates you give managment even if you don't specifically say that is part of the estimate) and use those test to makes sure later changes don't break something else.

You need to view this as a priceless opportunity to grow and improve. You have more freedom in the actual coding than many people have at that stage of your career. So consider this an opportunity to create a portfolio of successful implemented projects. When you do go looking for that next job, being able to point out such accomplishments as institutited source control, instituted bug tracking, created X number of successful project implementations, etc, will make you stand out from the rest.

You also have a great opportunity here to learn how to manage expectations upward. This is askill that will come in handy the rest of your career. You have nothing to lose in trying to do this here, things are already not good. But you can learn the political skills that will help you in better places later. Learn to do a cost-benefit analysis. Learn to undersatnd the business domain so that you can be convincing when you talk to them. Learn to talk in terms of benfits to the company and profit. Do estimations for every task you are assigned and even if they don't match waht management is giving you, keep records of what you estimated and what it actually took to improve your own ability to estimate work. Once you can show that your estimates historically have been more accurate than managment's, they will be more likely to listen when you tell them the estimate is too low. But you have to build a track record first of both more acfcurate estimates and most importantly, ability to deliver the projects and make them work. Again this is a good skill to have as you move up in your career.

Above all don't be passive and expect improvement to come from above.

Answer 3

...keep changing the requirement specification. Changes which, if good engineering be done and not patchy "fixes", require change in the underlying design.

Sounds like the real world. This happens all the time, everywhere. Yes it sucks, but it's bearable with some sort of agile attitude. Besides, one measure of software goodness is its malleability. Take it as a challenge.

A lot of jargon is used which makes sense grammatically but fails to make any sense any other way.

Again, doesn't sound so unfamiliar ;-)

There is no one who understands the complexity of what I am asked to implement.

Not even you? If you do understand that, then there's one person in the mirror who does understand that. So your responsibility of your company's well-being is probably heavier than your formal title suggests. If you do understand the issues and your manager doesn't, then it's your responsibility to make things clear to the management so that they can properly direct the company. It might be reasonable to assume that your nearest managers should be technically competent (not necessarily as competent as you - while they're managers, you're the expert - but at least a tiny bit competent), but if they obviously aren't and you could help them, why don't you?

A simple escapist solution is to switch company. But as an another option, consider implementing Joel test's items. Although items from 5 on require more co-operation with the management, items 1-4 are such that you could just set them up without asking anyone.

That said, no one here at SE can know your exact situation. It's possible that you're in a company crowded by incompetent jerks, and making something good out of such a mess could be too much for anyone. You must assess the situation yourself.

Answer 4

If I were you, I would try to find another job. Why? I think you know that, unfortunately, your manager is, well, "not good". You should try to work some stuff out with your manager though.

If you do not want to leave, and/or your not going to talk to anyone, then your going to have to find something yourself. If nobody in the company knows about your code, how is your manager supposed to know you meet the requirements? Just saying...

Answer 5

Talk to your manager and to the seniors about this. Explain your issues and suggest solutions. Prepare the talk a bit so you know the general message you want to convey.

After the talk, give it some time. See if things change or not. If they don't, try to implement changes yourself and show to the manager and seniors the positive results of your changes.

If the talk doesn't help and your changes are dismissed, you have to evaluate for yourself how much you like to work at that place. Yes, the work might be bad, but maybe the pay is good and you only have a commute of 5 minutes? Do the positive aspects of your job outweigh the negative? I they don't, I'd start looking for a new job.

Answer 6

Your problem is that ticketing systems and version control are TECHNICAL matters and you should be doing this regardless of the input of a non-technical manager. This should be assumed as a best practice technically and if they don't have this set up then you should take it upon yourself to make this happen.

You can't expect a non-technical manager to understand the benefits of defect tracking, source control and continuous integration. This is why they are non-technical, they are not supposed to know or care about that, they are domain and business knowledge experts. The only thing they should be providing is high level direction and requirements.

I have a non-technical manager as well and was able to increase the Joel Test score from a 4 to an 8 just because I went and did them and didn't ask for permission.

Your group needs a strong technical leader and nobody has stepped up to the plate.

Check out http://community.rallydev.com/ they have a community edition that does an excellent job of Agile project management and Defect tracking. That alone will bump up your Joel score and will cost you NO server space or time at all to set up.

Answer 7

I think there are missing layers of responsibility in your team. There should be a project manager, systems analyst, business analyst and developers. The Project Manager role is responsible for defining and enforcing the customer-project communication strategy (among other tasks).

Managers are not required to understand code or complexities. The need to understand, resources, cost and risk.

Source code versions, code quality, complexity, etc. are either the PM responsibility or the Senior Developer's.

Solution is to:

1-Define the project team structure and their responsibilities

2-Educate the manager in cases of software failures caused to bad management - Stay away from technical details. You can find some examples by googling.

Answer 8

If this is a small shop where you and the other "senior" are basically the only people coding, then it actually might be your responsibility to indicate to the manager what needs to be done to satisfy the "Joel Test".

Changes in requirements will always be there, and your job is to embrace them, which is one of base principles of agile development:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

But adapting to changing requirements means following other agile principles as well. At management level, this means manager must be able to transparently present to the customer that all such changes come with a cost: either the project's scope must be changed to satisfy deadlines, or deadlines must be shifted (the latter not being recommended).

If this is a sort of a project where your manager is the one who comes up with all the requirements, then you should act like he/she is your agile customer, and explain the same thing to them (scope <--> deadline compromises).

But at the developer's level in a small company, I would say that it is your responsibility is to ensure that coding part conforms to agile recommendations.

These are some steps you absolutely need to do, and probably you will need to do them yourself:

• you must have a version control system (takes one day to set it up for a small team)
• you must have build scripts to ensure that you can make releases often (pretty quick to set up also)
• you must use automated unit tests (this is a way of coding, and it dictates your entire design radically, so it might be difficult to add them in the middle of a tightly coupled project)
• you could also set up a continuous integration system to ensure automated builds and tests, as well as functional and GUI tests (which are a bit harder to write)

Remember that you can have a SVN repository locally on your own machine. A simple TODO list might serve as a poor-man's bug tracking system (a bit extreme, but hey). And there is no excuse for not having build scripts.

Also, before making any statements about scope/deadline compromises, someone also needs to make predictions about how much time a certain feature will take. This is usually done in "ideal days" in agile world, which means you should do your best to predict the relative effort of each feature, and then use your actual coding speed to see how well you predicted (and scale the "curve" accordingly).

Answer 9

Especially regarding there being no one who would point out improvements in my code.

Couldn't you try to set up code reviews so that there are people looking at the code? Are there conventions and standards that would help give the code some structure? This is presuming you aren't the only developer there of course.

While you are likely in a less than great place, does it look like it is working in the end? Are projects getting done and things are moving forward? Are things getting done? The Duct Tape Programmer would be the Joel article that you may want to read.

Answer 10

Option 1 - tell them 'with all the changes you are making to this project, by the time we deploy it, the system will run very slowly' or 'the customer won't be able to figure it out'. Your managers don't care about spaghetti code but they do care about customer. Pitch the problem to them in terms of what they comprehend, not in terms of code writing.

Option 2 - give them what they want. When they complain about something you say 'but that's what you asked for'