Fog Creek Software
Discussion Board

developer doing design,testing,documentation

I am a single programmer working on a reasonable size data mining project.In addition to design, research, finding appropriate algorithms, coding etc.. I am spending a whole lot of time in testing and documetation in the project,
how do other developers balance these aspects?
I am finding getting immersed in testing, I am neglecting other developmental activities.
I work in small company with no testers or tech. writers, how to balance out the responsibilities, given that I am primarily a dev. guy?

Saturday, June 28, 2003

I think that testing _is_ a development activity. If I don't test your code, I can't be sure neither that I've build the right thing, nor that I've build the thing right.
That said, I think that you should try and automate your tests. This way, the time you spend on testing is just the time needed to code them.

As for the documentation, what kind of documentation are you talking about? User Manual? API reference?

Giovanni Corriga
Saturday, June 28, 2003

Errata: It should have been 'if I don't test _my_ code...'

Giovanni Corriga
Saturday, June 28, 2003

unit testing is one thing - UAT/system/regression testing - are not (IMO) developer activities - requires a different set of skills (and a completely different attitude).

Saturday, June 28, 2003

Actually, this doesn't sound so much like a "what responsibilities belong to developers" question as it does a workload management question.

Your situation may not be ideal when it comes to a developer environment but you're stuck with it (unless you can convince the company to hire a tester). In that situation, I would say that the most important step is to try to get rid of the attitude that testing is somehow diverting you from "more important" developer tasks. Since you are literally "it" on this project, it's ALL important.

Do you create your own schedules as well? Or do you have a manager or someone who does this? Either way, you have to be more involved here and work to create sane schedules. Single threaded development teams are much more sensitive to disruption, etc, so you should be building more slack into the schedule.

One thing we've definitely learned in our group is that developers almost invariably underestimate the amount of "noise" in their daily lives. I would recommend really trying to figure out what proportion of a normal 8 hour day you actually spend working on the project and what you have to spend on "infrastructure" work. That can help you when you're scheduling.

Good luck.

Saturday, June 28, 2003

I'd say, set milestones for yourself. Have a certain amount of functionality done every couple weeks, and devote, say, a full day or two at the end of those two weeks to test what you just wrote.

Brad Wilson (
Saturday, June 28, 2003

find the eventual user and get them to do the testing on the UI

automate the API based tests

Daniel Shchyokin
Saturday, June 28, 2003

My opinion: your company needs to hire some testers.

Unless your project is trivial, it is a mistake for testing to be done by the same people who wrote the code.

Ideally, you should have some dedicated test folks who are responsible for the end-to-end testing process, including component testing, integration testing, API tests, perf testing, scalability, customer scenarios, etc.

Your role, as the dev, should be to own unit testing (usually very basic component tests created around knowledge of the internal workings of the code), and take responsibility for executing automated tests (BVTs, acceptance tests, etc.) provided by the test team when you make changes to the code.

I think most people would also agree that having developers document a product is less than desireable.

Obviously saying "hire some testers and writers" is easier said than done, but your product quality and schedule will suffer if everything is owned by the dev team.

Mike Treit
Saturday, June 28, 2003

I always thought a developer did test, code design, documentation, and analysis. I guess it goes back to job titles mean different things at different places.

Saturday, June 28, 2003

In my small company every developer does everything.  Beyond the time I take personally for testing and documenting, I send continuing versions out to my actual client ( in the govt. ) who uses it in his work, then calls back with complaints and suggestions, leading to continuous bug fixes and additional features ( my boss, also, has a continuing flow of new feature suggestions ).  Somehow, it all seems to work and the client gets his work done, too.

Barry Sperling
Saturday, June 28, 2003

The answer is:  you can't balance these aspects.  Alchemists can't turn lead into gold, either.

Developers should unit test and do basic integration testing.  They should communicate their technical decisions on a certain level.  Beyond that, they're fish out of water.  You don't have the unbiased perspective to do decent testing, so your customers are going to test the product.  That's just a fact.  It's not pretty, but it's likely true.  And you are not a documentation person, and writing decent documentation is very time-consuming, so chances are your documentation is going to suck, unless you are an English savant.  Again, a not-pretty fact.

And I don't agree that one can stretch the schedule in this case.  A company that doesn't have the money to hire testing or documentation resources probably doesn't have the money to stretch release schedules, either.  If they do have that kind of money, then they're probably managing it very poorly by not spending it on testers or documentation (since it's pretty well-established that both, especially testers, generally produce a good return for software projects).

So what you have is a conundrum, and it's one I know very well:  you have three full-time jobs, and only one full-time. :)  My suggestion is really quite simple:  do what you know how to do, well, and do everything else to the best of your ability, and that may not be very well.  Don't worry about "balancing," because you just can't be a jack of all trades and master of them all.

Anyway, this is a business problem, and so I hope your business has a great justification for contuing to impose it on you.

Sunday, June 29, 2003

>> I work in small company with no testers or tech. writers

Everyone: This sentence in the original post says it all.

I've made my coin for years in software product development for small companies, as a consultant. What happens in the very smallest companies (including some quite successful ones in their respective realm) is that there is simply no money, time, willingness, or conceptual ability to deal with more players than one or two "jack of all trades" person. Today I want to beat that last attribute, "conceptual ability" into the ground...

Small companies exhibit both the best as well as the worst aspects of commercial life. The best aspect is that workers in that context tend to be extraordinarily motivated and self reliant. The worst aspect is that owners can be extraordinarily cheap, stupid and short sighted, and they can be very successful even though they do all the wrong things.

It's like an old slogan I saw in an underground comic: "if I can't eat it or f*** it, then p*** on it." Small company owners tend to have to see a direct physical relationship between an activity and an income producing product. They tend to be fairly incapable of the sort of abstract reasoning that allows them to understand that certain processes (such as test or documentation) complement direct tech work and result in higher quality for the user and thereby a competitive advantage. They just can't and won't believe, for instance, that test or docs aren't best done by the person that develops the code.

Note to anyone proposing to hold income producing business owners on a pedastal as a higher and Godlier  form of life: absolutely don't. I work with a person in this context, a self made millionaire, who essentially lives and acts like a 5 year old and treats his employees and their own time like his personal possessions. I know a partnership of people that lucked into early success who are egotistical self centered jerks. Success spoils.

Bored Bystander
Sunday, June 29, 2003


You really said it all.  If it won't offend your copyright-holdign status, I want to have that post framed and placed on my wall.

I have a personal saying, from my experiences in a small company:

"Wanting to work for a small company is like wanting to live in a third-world country."

Sunday, June 29, 2003

Multi-facet: trade yah... ;-) Sure.

>> "Wanting to work for a small company is like wanting to live in a third-world country."

LOL! How true.

Bored Bystander
Sunday, June 29, 2003


I have been working for a bigger company for two months
as contractor. Untill now they have paid me for the previous milestones of the project (billed seperatly).

Now yesterday they told me that they are closing the quarter in terms of finances, and therefore they must skip payment into the next quarter budget ... meaning i have still a month to wait for my money.

Michael Moser
Tuesday, July 1, 2003


I am in a similar position.  I do everything in my little one person company.

I do Development, design & usablity testing, documentation, support, marketing, and sales.  And I work a reasonable schedule (avg about 40 to 50 hours per week, but it could be shorter if I weren't on Jos all the time ;-).


This is because of the overlap between responsibilities.  What you learn when doing support feeds directly into design and documentation.  So, when I found that our install was more complicated than needed (I found myself saying "just press <enter> <enter>... take all the defaults") I made it simpler. Likewise, I simplify the design and UI (often based on support feedback) to reduce the need for documentation.

1.  I cycle through each phase for a while.

So... I might work on our catalog for 2 or 3 months.  Then I might work on a new version for 2 months (updates), then work on a new program for a few months.
There's a certain "activation energy" needed to start any of these activities. I use the analogy of surgery: there's an overhead with surgery (anesthesia, scrubbing in, recovery, etc.).  So, you try to do all the cutting at the same time, to make the most of that surgery visit).

2.  I keep a "to do list" with bugs, feature requests, etc.

This greatly facilitates the above.

3.  I try to remove redundancy.
If I get a lot of calls about something confusing, I might explain it in the documentation. Then, over time I discovered that it's even better to just make the program simpler. Now, that eliminates TWO bits of redundancy (documentation how to do it and then explaining via tech support).

In fact, we don't have paper documentation.

And we are never asked for any (once the customer gets the product).

Occassionally, peope will ask before buying and I just say "we're so confident it's easy to use that we provide a free 800 (no waiting!!) if you need help.  RARELY get calls these days. And those are the sort like "OK, I wrote 'click' on my desk[top]. Nothing happened.  You said 'write-click on my desktop".. Sigh...

Wednesday, July 2, 2003

*  Recent Topics

*  Fog Creek Home