I work for a small electronics and support software company that just recently got a contract with a large company that's very strict on documentation (I do the support software, essentially Windows or browser applications). Upon reviewing the required documentation from the large company, I realize that I wear more hats than I realized. Namely, we have to produce documentation describing:

  • Requirement analysis (me)
  • Architectural design (me)
  • Detailed design (me)
  • (Actual) Software development (me)
  • Database design development (me)
  • Testing plan, preparation, and results (me)
  • Proof of compliance with requirements (me)
  • User manual (me)

I'll also be doing most (if not all) of the testing myself. And the deployment, training, and customer support. If there's any application technician needs for sales support, that's me too.

Is that common? Do small software companies that get big contracts ask that commonly from single programmers?

  • I tried to edit the title to reflect the nature of the problem. If you do not agree with my change, please kindly roll back. Thanks. – rwong Jul 29 '11 at 7:24
  • 1
    In small companies you need to wear many hats. Is the problem the number of hats or the work you have to do? – user1249 Jul 29 '11 at 8:04
  • @Thorbjørn I'm just wondering if that's actually standard practice. The structure of the documentation would suggest a lot more people to do the work (and steps before the actual code is written). That means for a month, what I was hired to do (making software) has to be put on hold. And that's not a calendar month, that's a month stretched out over a few calendar months with the other projects always running. I mean, some documentation is part of "making the software", but here, there's 0 code for a long stretch of time, meaning nothing's running. – MPelletier Jul 29 '11 at 10:45
  • 1
    MPelletier - If you are asking if doing all the documentation is standard I would help you would have done it anyways. Doing design documents is part of the process to produce software. How can you verify what you produce actually works without requirements? – Ramhound Jul 29 '11 at 10:49
  • @Ramhound: I usually verify that all requirements are fulfilled when I have said requirements (not always the case as you can imagine), and with a lot less red tape. – MPelletier Jul 29 '11 at 11:02

You're getting paid for all of these things, right? So it shouldn't really be a problem.

It's not exactly economical for the client. Requirements analysis is typically done by a business analyst, and the user manual is typically written by a technical writer, both of which are significantly lower-paying jobs than a senior programmer.

As for the rest of it, I'd say yes - if you're running a one-man shop (or a very small shop), then as the "solutions guy" you're definitely going to be doing the architecture, database, code, and much of the test plan on your own. The test plan you'd be doing with significant input from the business people, although the actual testing itself might be more typically sent to a QA department, or even to a "focus group" of actual business folks.

Deployment, training, and customer support... that's where it starts to get a little murky. In a corporate setting you rarely see developers doing that, because it's just a massive waste of time. Sysadmins handle deployment, BAs and helpdesk handle training and support respectively. Developers are not only an extremely expensive support vehicle, they're also not as good at it as somebody less... well, I might as well just say it, socially awkward.

On the other hand, it's quite typical to be doing these things yourself if you're doing consulting independently or in a small group. First of all, who else is going to do them? And second, consultants have a lot more "human" experience so they'll actually be fairly good at it, at least if they've had a few clients under their belts.

I think that the smaller the company, the more hats you are going to wear. Some people will say that it's a false economy - and it's true that writing a user manual is not an efficient way to fill a developer's time - but at the same time, if they only need you to spend 2 weeks a year on documentation then it makes no business sense to hire a full-time tech writer.

Part of this depends on your area and the job market. If it's relatively easy for you or your company to swing a short-term contract with a BA, or a tech writer, or a tester, or a support tech, then it may make sense to do that instead, even if you have to spend a little time training them. It can't hurt to suggest it to your boss - if he's the non-technical type, he may not even realize that these specializations exist.

But even with informed management, it's not uncommon in any way for developers in micro-ISVs and non-software small businesses to be doing most of the ancillary work themselves. If the client and/or company is willing to pay developer rates for testing work, I see no reason to fight it, unless you really hate doing those things (in which case you should be asking a very different question).

  • I wish I was getting paid all these different job titles' salaries. Or if I can pick, I'd take architect. – MPelletier Jul 29 '11 at 3:17
  • The write-up on this current project will be 4 weeks. That's just one project out of several this year... But I see your point. – MPelletier Jul 29 '11 at 3:17
  • 1
    @MPelletier: I didn't mean that you'd be getting paid all those salaries simultaneously, just that you're getting paid the same amount for your time regardless of whether you're doing the development work or the other work. – Aaronaught Jul 29 '11 at 3:23
  • I know you didn't mean it. I'd be paid the same amount to mop the floors if that's what they wanted me to do, which is not fine because I'd get paid the same to mop the floors on top of doing the rest of my work in the same amount of time. I have several other projects that need to move. – MPelletier Jul 29 '11 at 10:59
  • 2
    @MPelletier: I understand completely, although you're asking a very different question now ("How can I avoid getting tied up in non-code activities?") and the answer is "work for a larger company with specialized staff." It's all about your career goals; if you aspire to move into consulting or start your own business then this is great experience to have; if you really just want to write code or maybe do system designs, small businesses and micro-ISVs are a crap shoot. – Aaronaught Jul 29 '11 at 12:26

I have found this to be true of small companies regardless of contracts.

For smaller companies I have found that I've been placed into hybrid roles such as:

  • Software Engineer
  • Documentation
  • Analyst
  • System Support
  • Customer Support (to a lesser extent)

In general I've found the small companies and start-ups cannot afford to hire extra staff to full-fill most of those roles, as they are not required often enough to advocate hiring extra staff or specialists.

I recommend that you take stock of your current abilities and time. Make it clear to your boss that your new responsibilities will spread you too thin and they should consider hiring more people to help you to successfully full-fill the new contract.

  • Cashier? Now that's seriously wrong. – MPelletier Jul 29 '11 at 3:07
  • @MPelletier - I had my own startup (with 4 other directors). So cashier was more of a fill-in position. – Justin Shield Jul 29 '11 at 3:16
  • @MPelletier - I would have to agree doing all of those things by yourself is tough. While I do those things daily I also have support if I need it. – Ramhound Jul 29 '11 at 11:59

Thinks of the “required documentation” as a check list, there is nothing saying that a given document has to be more than a few sentences long. However write each document so it can be reviewed by someone that has not read the others.


It would be beneficial to hire a Virtual Assistant, although you will have to take on having to explain everything (time consuming).

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