Being a developer, project manager and everything else concurrently

Question

Disclaimer: This is not an explicit programming question but it is about software development.

I understand that a lot of guys out here work in a small organization and play multiple roles. I've learnt back in school (if I remember correctly), that in a software development project, certain roles/hats cannot be played/worn by the same person.

Something along the line of:
- Tester cannot be the one testing his own code
- Project Manager cannot be the developer as well

Unfortunately in my organization, I am the technical project manager, who manages a programmer (myself) and a tester (myself). Which obviously means I'm testing my own code. The others in the team are the design guys, thankfully is not me.

I'm getting pretty worn out and considering the fact I have a boss who will restrict my interaction with clients, it's kinda hard to manage clients' expectation as my boss is not technically inclined.

My testing process is hardly formalized/structured and there are loop holes that I didn't cover as I didn't really try to be a dummy user. I might if I have the time. The problem is clients end up as our alpha testers (instead of beta, bad bad).

I am dead sure big chunk of SO guys are like me, how do you guys manage?

PS: This post is wiki-fied in an attempt to gather feedback and suggestion to help anyone else in the same shoe as me.

Answer 1

Testing is one thing which is difficult to do yourself. Fortunately you'll hear about problems pretty quickly in a small organization and soon you'll learn who it is that finds most of your mistakes. Once you know who that is create an early adopter group made up of these people and have them test out new things you deploy.

I don't think that project manager and developer are all that incompatible. Track everything in bug tracking and give them priorities based on what the customer wants.

Answer 2

if you have unlimited resources and a waterfall methodology, those adages will be helpful in establishing a separation of concerns - unfortunately they can also work to establish fiefdoms and barriers to communications

in small organizations, wearing multiple hats is the norm - there is no other option.

It helps to focus activities in the context of one role or another, and not both simultaneously

on the other hand, there are quite good methodologies (XP/TDD for example) where the developer is expected to test his/her own code

it sounds -offhand- like your organization would benefit from using XP and increasing the exposure of developers to customers directly; whether your boss would agree with that statement or not depends on his/her point of view of the current situation!

Answer 3

I know a guy that beta tested his own code and did a great work at it.
It's all a matter of patience and self-discipline.

And time - heckloads of time.
Clicking every botton there is, tracking everything the application is supposed to do.

If you're meticolous you can do it, but do not underestimate the time it will take. In a team of two developers, half of your time will end up being devoted to testing.

On the other side, maybe you just don't have the patience, or the strength to use what you are already programming. Personally I don't. Unit testing on a file or class level can help you keep you application sane. (so you don't make a fool of yourself in front of application testers with an application that doesn't even start/install/does anything at all/does it wrong)

On the application level I prefer non-tech (albeit non-illiterate) people do the testing. Being able to listen to them while they are testing is a plus: when they ask for help there usually is an UI design bug to squash.

I'm not entirely against clients doing tests. Tech people on the client party may like to get involved in the process and find it a good distraction from everyday troubles.
Sometimes anyway new, unwarranted for, requisites emerge from such interaction: if you couldn't foresee it, can't renegotiate the terms, and/or have your boss understand what happened... ugly situation.

Anyway locked away from customer interaction AND tight on resources is a receipt for disaster. Not talking about simple, single, well defined disasters, but a neverending series of pyrrhic victories and delays.

Is that a case of deliberate mushroom management or just a number of unfortunate circumstances?

If the second case, talk to your boss about it, cooperation with the customer can ease a lot of pain from small houses and even has that trendy name to market it with: XP.

If it's of a deliberate strategy... I doubt there is a solution, or at least I couldn't find one, and quitted.

Answer 4

About testing, test while you're coding.. that's right (read on).

One thing I learned over the years is to be vigilant on small things.

Take a function for example.. If you assume the incoming parameters (or the current object state in case of OO) are safe, then you're in trouble. You're also in trouble if you return invalid values from the function (or leave the object in an invalid state after the call).

What I do for functions or process or whatever that have an input/process/output is:

1. I verify the validity of each of the inputs AND the environment state related to the process and throw if there's anything wrong
2. I do what I have to do
3. I verify that what I'll be returning is valid and throw otherwise
4. I test this function for ~every cases (limits) and I mark it as done in my head.

It may appear evident at first but look at it this way: If every small blocks of code are robust, putting those blocks together will make a whole robust, right?

For a lot of cases, yes. But if the execution thread is wrong (the path taken across your blocks), you can still have a bug.

It always worked great for me and when I have a bug, I'm never too deep in the stack before knowing it and since I throw descriptive errors, the diagnostic is never too hard.

Paranoia can have bright sides!

Answer 5

Is your time tied-up and functions you have to implement fall in such lots that you always work in XP mode?

In any way you can spend this little time more effectively: make some scrap of architecture to quickly reference different segments of your solutions, auto-generate new types and class changes through UML (there are tools that can re-engineer and include previously implemented code on regeneration stage, e.g. Enterprise Architect), auto-generate unit tests (and here you better have transparent architecture) and some tools like ReSharper to increase your speed on trivial tasks (and yes, coding is usually one of these). And as addition, you need good job-site that will increase you reaction and ease your mind :) (preferably multi-screen setup).

Summarizing: discipline, best tools and practices (simplified for ease of support) and productive and clean job-site.