I'm a software developer working in an embedded systems company. We have a Project Manager, who takes care of the overall project schedule (including electrical, quality, software and manufacturing) hence his software schedule is very brief.

We also have a Software Manager, who's my boss. He makes me write and maintain the software schedule, design documents (high and low level design), SRS, change management, verification plans and reports, release management, reviews, and of course the software.

We only have one Test Engineer for the whole software team (10 members), and at any given time, there are a couple of projects going on.

I'm spending 80% of my time making these documents. My boss comes from a Process background, and believes what we need is better documentation to improve software:

  1. He considers the design to be paramount, coding is "just writing the design down", it shouldn't take too long, and "all the code should be written before the hardware is ready".
  2. Doesn't understand the difference between a Central & Distributed Version control, even after we told him its easier to collaborate with a distributed model.
  3. Doesn't understand code, and wants to understand every bug and its proposed solution.
  4. Believes verification should be done by developer, and validation by the Tester. Thing is though, our verification only checks if implementation is correct (we don't write unit tests, it's never considered in the schedule), and validation is black box testing, so the units tests are missing.

I'm really confused.

  1. Am I responsible for maintaining all these documents? It makes me feel like I'm doing the Software Project Management, in essence. I'm ok with technical documentation, but I believe scheduling/planning should not be done by the developer.
  2. I don't really like creating documents, I want to solve problems and write code. In my experience, creating design documents only helps to an extent, its never the solution to better or faster code.
  3. I feel the boss doesn't really care about making better products, but only about being a good manager in the eyes of the management.

What can I do? This whole year I've done 3 months of actual coding, the rest just spent in making documents and waiting for bug reports from clients.

  • 16
    If he is your boss and says you are responsible for those documents, you are responsible.
    – Rig
    Nov 29, 2012 at 15:57
  • 1
    The Software Manager is just another term for the Product Owner. This is usually a non-technical role so he shouldn't be writing technical documentation either. They basically work with clients and stakeholders and make decisions about what features and changes need to occur in a given product at given releases. They mitigate the complexity of having multiple stakeholders with different competing needs.
    – maple_shaft
    Nov 29, 2012 at 16:27
  • 2
    I've tried to bring that up a few times. Trouble is, I don't know how much of the scheduling effort should come from the PM, and what role will my SM play in this. As of now, I'm the one making all the Software Gantt charts, resource allocation, Software Requirement Specification, Traceability Matrix etc.
    – user73964
    Nov 29, 2012 at 16:45
  • 1
    @hdman Now thats a little different. The PM should be doing Gantt charts, resource allocation and traceability matrix. What then does the PM do?
    – maple_shaft
    Nov 29, 2012 at 17:37
  • 1
    @maple_shaft I'm a young guy, and I want to create things, code and try out new stuff. I'm not really interested in taking project management as a career choice. I guess it might be time for a change.
    – user73964
    Nov 30, 2012 at 2:57

5 Answers 5


You sound like a Software Engineer.

A Project Manager is more focused on the status of the overall project and allocating resources in an effective way to ensure that milestones are being met and in proper time. They also remove roadblocks and help the project resources focus on their specific job functions.

Writing and maintaining design and technical documentation is an important part of being a software engineer and is appropriate for your role. Too much of a good thing can be bad though (See Analysis Paraylsis ).

He considers the design to be paramount, coding is "just writing the design down"

If the project manager considers the design documents to be paramount then he expects the documents as a deliverable in the process. It is not a wasted time on your part if he feels they are important enough to allocate 80% of your time to it.

it shouldn't take too long, and "all the code should be written before the hardware is ready".

This is wishful thinking and quite an antiquated Waterfall style view of how software development works. It invariably is never that clean no matter how much design and preparation that you devote. On that note however, you should have clear hardware specs and proper test environments and mock hardware simulations for your code to interact with but again, the real world is messy.

Project management is incredibly easy in a perfect world. The world is not perfect however no matter how much you wish it to be so making real project management incredibly difficult. This is why they are paid the big bucks.

(2) Doesn't understand the difference between a Central & Distributed Version control.

Why should he care? How does it affect the milestones? It doesn't.

3) Doesn't understand code, and wants to understand every bug and its proposed solution

His goal is for working software and yours should be too. He does not need to understand the code but he does need to understand the issues that are preventing working software. Once the two of you see eye to eye on this basic level then your mutual goal will help you work together more effectively.

(4) Believes verification should be done by developer, and validation by the Tester.

What is wrong with this sentiment? Testers in the quality assurance role should be concerned with validating features and requirements. Developers should make every effort to verify and test their work before it goes to testing.

I don't really like creating documents, I want to solve problems and write code.

If you would rather be a simple programmer then perhaps you should talk to your boss about this and see if there is a better role for you on the project. Somebody needs to write and maintain the technical documentation, so perhaps one of the other developers can help you with some of these tasks so you aren't spending 80% of your time writing documentation.

In my experience, creating design documents only helps to an extent, its never the solution to better or faster code.

This is mostly true... but only if all ten developers are spending 80% of their time writing technical documentation that nobody will ever read. This is an enormous management anti-pattern that I have lived in before. If you find that you are doing most of the documentation for the team then it hardly seems fair that you are denied the right to perform more coding work.

The fact of the matter is that the best technical documentation is the code itself.

I feel the boss doesn't really care about making better products, but only about being a good manager in the eyes of the management

I feel that he does care because the product is his ward and if projects and features are not completed and clients aren't happy then upper management will not care for him very much. The problem is that your perspective on the necessary quality improvements don't match with his, and upper management, and the clients perception of what they feel is important.

Try to understand what is truly important for the product, because while you can increase the efficiency of a process 3 fold, if you spend an entire week doing this then it is at the cost of another important feature that the client is demanding.

We all want to look good to the eyes of our superior. There is nothing wrong with that, it is human nature to be self serving. This is a fact of life.

  • 1
    Thanks for the answer, I agree on some points. But whats the role of the Software Manager then?
    – hdman
    Nov 29, 2012 at 16:28

To some degrees, I agree with your project manager. Software development goes well beyond coding features. :-)

Given your situation, I would go to him and explain that his requests are taking 80% of your time, and seek to understand why it is important for him that you spend this time maintaining documentation rather than developing (which goes beyond coding).

FYI, Atlassion, a software company, has a ratio of 13 developers for one QA person and most of the testing (planning and execution) is done by the developers. I learned this during one of their presentations at Agile 2012 and our teams I currently trying to emulate this practice.

However, I would also discuss with your project manager if he would be open to try out Scrum as a methodology to help move the whole team forward. Given your description, I don't think you are using Scrum.

Like you, I was extremely frustrated at maintaining plans that were constantly changing and a Scrum lightweight approach helped me overcome this frustration.

  • 2
    Thanks for the answer. I've tried suggesting Agile, but they want to follow CMMI. Also, did I mention I also have a Software Manager?
    – hdman
    Nov 29, 2012 at 16:22
  • @hdman Well, let's be realistic here. You need to have a conversation with both of them and express that you care about the big picture: Making sure that the team is as productive as possible so the company can increase revenue. These conversations may go well or they may not but it is your responsibility, as a professional, to bring it to the table and it is up to them to act on it or not. Make sure to bring is in a positive manner, not 'whining' about the situation but wanting to improve the situation for all. Nov 29, 2012 at 16:24
  • I agree, but the thing is I'm the youngest in a primarily middle to old aged environment. Most of the time it boils down to me being inexperienced.
    – user73964
    Nov 30, 2012 at 1:14

The most performant teams in my experience were those that faced the least amount of process necessary to do their work. At some point additional process starts taking away quality from the product. If QA starts to miss bugs because they are more concerned with getting paperwork out of the way, and DEV isn't coding features or fixing bugs because they are writing documentation then you have a problem. However, figuring out of if this is actually the case in your company is a highly localized question that only people on your team can answer (not us).

There is one thing that your boss is very wrong about, and that is the fact that you have so little QA and no unit tests. A bug created by adeveloper is by definition an oversight on their part. Expecting developers to always test their own features and having little testing aside from that is a process problem. QA can be replaced by automated testing depending on your domain to an extent, but if you have neither then you're probably letting bugs slip through (and that usually ends up costing more than finding them early).

Also, from a strict business perspective, hiring QA is cheaper than hiring developers. You will be able to cover more ground for the money spent if the teams have a good QA/DEV ratio.

  • QA can be replaced by automated testing depending on your domain -1 I disagree vehemently with this. No amount of automated testing is a viable replacement for QA, most especially when special hardware is involved.
    – maple_shaft
    Nov 29, 2012 at 17:58
  • 1
    @maple_shaft Corrected. I meant QA can be replaced to an extent depending on your domain. For example if it is a controller device for some machinery you know that given certain inputs you expect certain outputs - this can be automatically tested. However if it is a GUI application then there's no way around having real people sitting around and poking at it.
    – MrFox
    Nov 29, 2012 at 18:52
  • Awesome! that makes more sense now. I reversed my downvote, +1
    – maple_shaft
    Nov 29, 2012 at 19:00
  • We don't really have a QA department. We have one tester, and there's the QE dept. that does overall quality control for mechanical, mfg, reliability etc.
    – user73964
    Nov 30, 2012 at 1:08

The CMMI implementations I've seen or directly heard about have all been process and documentation heavy; your bosses belief that the documentation should be detailed enough to make the implementation trivial strongly implies that his expectation is similar.

If you're receiving a disproportionate share of the documentation writing/maintenance, asking that it be more evenly distributed is reasonable. If the other developers have similar documentation to coding ratios and you want to spend most of your time writing code; it may be time to consider finding a new employer.

  • Exactly. He's totally about CMMI. Now we're level 3, he wants to go for level 5. The 'lead' does most of the planning/scheduling work, which I'm doing now. But our organization structure makes all SEs equal, so one person is chosen as the lead and given all this work, there's no permanent lead per se.
    – user73964
    Nov 30, 2012 at 1:02
  • And I'm seriously thinking about your last sentence. Here it seems like I'm stuck in the 70s with the rest of them, where code complexity is counted by number of lines. It seems people here don't want to change their ways, there's no creativity.
    – user73964
    Nov 30, 2012 at 1:17
  • @hdman There is nothing wrong with that and it is not necessarily yours or their fault. Sometimes people just don't fit in well to an environment.
    – maple_shaft
    Nov 30, 2012 at 2:18
  • Yeah, I guess it might be a culture issue.
    – user73964
    Nov 30, 2012 at 3:00
  • At level 5 the paperwork burden is going to be massive; sounds like it's definitely time to flee. Nov 30, 2012 at 13:36

You're talking about medical systems... so safety is paramount - and therefore the documentation (specifically traceability) is essential.

One tester seems a bit light, but other than that, yes - you are responsible for ensuring the documentation is in place.

My experience in the medical world is limited, but over in the aerospace/defence world we have Do-178B (now C) which prescribes a lifecycle model that specifies the documentation and level of testing necessary (depending on the safety criticality [more specifically, the design assurance level] of the software), and in the automotive world we have ISO26262 which does likewise.

If the documentation is not in place, the product doesn't get certificated.

But the important thing is to work with the required documentation to make your product better... do not try and reverse-engineer the documentation as an after-thought because then it serves no real-world purpose.

Your Answer

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