What kind of software development process should a lone developer have?

Question

I work as a lone developer in a very small company. My work is quite chaotic and I'm looking for ways to make it more organized.

One problem is that my projects have practically no management. Rarely anyone asks me what I'm doing, or if I have any problems. At some point there was talk about weekly status meetings, but that's some time ago. Seems that if I'd want something like that, I would have to arrange those myself.. Sometimes I'm a bit lost on what I should do next because I don't have tasks or a clear schedule defined.

From books and articles I have found many things that might be helpful. Like having a good coding standard (there exists only a rough style guide which is somewhat outdated in my opinion), code inspections, TDD, unit testing, bug database... But in a small company it seems there are no resources or time for anything that's not essential. The fact that I work in the embedded domain seems to make things only more complicated.

I feel there's also a custom of cutting corners and doing quick hacks on short notice. This leads to unfinished and unprofessional products and bugs waiting to emerge at a later date. I would imagine they are also a pain to maintain. So, I'm about to inherit a challenging code base, doing new development that requires learning a lot of new things and I guess trying to build a process for it all at the same time. It might be rewarding in the end, but as not too experienced I'm not sure if I can pull it off.

In a small shop like this the environment is far from optimal for programming. There's many other things needed to be done occasionally like customer support, answering the phone, signing parcels, hardware testing, assembly and whatever miscellaneous tasks might appear. So you get the idea about the resources. It's not all bad (sometimes it's enlightening to solve some customer problems) and I believe it can be improved, but it's the other things that I'm really concerned.

Is it possible to have a development process in a place like this?

Would it help to have some sort of management? What kind of?

Is it possible to make quality products with small resources?

How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?

Maybe there's someone working in a similar shop?

Answer 1

1. Use Source Control for EVERYTHING
2. Develop specifications and get signoff before starting - there will be resistance, but explain it's for their own good.
3. Unit tests! It hurts because you just want to get it done, but this will save you in the long run.
4. Use bug tracking - Bugzilla or FogBugz if you can afford it.

Answer 2

You need to work with the owner and setup short medium and long term goals. You will want to let them know progress even if only through email.

You will need to enforce some order on your workday or you will never get anything done (those long term goals).

Divide your day up into chunks when you can code, when you are working on hacks to keep it togther, when answering emails etc.

Definitely setup a bug tracker. This can help keep your email clean. You can even setup an email address to forward bugs to be categorized later. This is good because the bug reporters will eventually tire of the bug tracker and want to just email you the bugs anyway.

edit

And as lod3n said, source control, but you are using that already right???!!?!

Answer 3

Have a bug tracking system, both for defects and new features. Don't rely on your memory.

Continuous integration and an automated build can help even a single developer.

Can't emphasize the recommendation for source control enough.

Answer 4

I've decided I don't need unit tests because I can have automated functional/integration tests instead: because with incremental development there's no need to test before integration.

Answer 5

First, lets make a distinction between a development process and best practices. Best practices like source control, defect tracking, unit testing, etc. are an given.

Then there is the actual development processes. I would always recommend having a process, no matter small or large the team is. The trick is finding the right process. You have a process now - it is just an ad-hoc process that doesn't seem to be working out too well for for you. Rarely can you take a textbook development process and directly apply it. What you need to do is tailor the process to your companies needs and culture. Look at as many development paradigms as you can and try to find something that is a good fit and them start molding it to your needs. You may have to try and fail with a number of different processes. Perhaps the Personal Software Process will be a good starting process, maybe an agile process, a variant of RUP? You have a lot of options, start trying them out.

You are also going to have to work with the rest of your organization - they need to be a part of the process. You may be the lone developer, but a development process involves more than the developer, it involves ever person that has a say or impact in the product.

This may not be a specific answer, but my point is that you will need some kind of process. So start researching them and trying them out and molding them to your needs until you have something that works.

Answer 6

My advice is not to be extreme. From my experience, pure agile or pure traditional will not work. Before you use any process, know what it mean to solve.

I personally use a variation of Agile RUP. I do some upfront effort such as investigate the actual needs, do high-level design with possible extension. And ask customer to sign-off some major high-level requirements.

If you work in small group, detail design or specification may not worth. Of course, if there is some libraries that are shared by many, it will be worth the trouble.

Deciding what to invest in up-front depending on its risk (likelihood and effect).

Moreover, many SW best practice is really 'best' like version control, automatic testing (to me I only used it way to early detect regression as I do not believe in TDD as driven force of the development). I suggest you read 'Pragmatic Programmer' it presents many of those techines.

As to answer you questions:

(1). Is it possible to have a development process in a place like this?

Yes, but as I say, trailer it to fit your organization.

(2). Would it help to have some sort of management? What kind of?

Management helps but no control freak. Plan what to do when: integrate, resolve conflict, dead line of some mile stone. And roughly keep them on schedule (I particularly like Scrum's sprint).

(3). Is it possible to make quality products with small resources?

Definitely as soon as the size of the work, the time to develop and the size of the team is balance. If you definition of Quality is the same with me. To me, Quality means: solve the problem it set out to in an efficient and reliable fashion.

(4). How do I convince myself and others that the company which has worked successfully for decades needs to change? What would be essential?

Point out the problems. If there are none, why change? If you want to change, you should be able to identify the problem OR potential problems. Point out the problem.

Some big one are:

• Without any process, it is harder for new recruited to blend in as they must learn from observing other how to deal with things.

• Without process, it is harder to work in stress.

• Without schedule, it is hard to determine the progress.

• Without automatic testing, it will takes more time to identify problems and regression.

• Without version control, it will be harder to roll-back mistake and separation of work to each team members will be mess.

Just my though.

Answer 7

Been there, done that.

The book Planning Extreme Programming helped a lot. I used 3x5 cards stuck on a wall. This kept my boss informed of my progress, helped with estimates and planning, and kept me on track. The Planning Game gives good ammo if your boss's expectations are unrealistic.

Unit testing, as others have stated, helps even if you're a sole developer. I find the TDD style valuable.

lod3n is absolutely right about Source Control.

I've gone with XP-style iterations before; you may want to establish a backlog of items (even something simple like a spreadsheet or 3x5 cards) as well.

Avoid deathmarches. Stick to 40 hours in the sense of not working overtime 2 weeks in a row. Spend extra time outside of work learning new skills - not just technologies, but principles and best practices.

Answer 8

as crazy as this sounds I use scrum just because I like the concepts of sprints, and backlogs. It makes it easier to set realistic goals. Of course the idea of scrum master and team is all you but if you are working on outside projects where it is possible that you may pick up an extra team member with your backlogs it will be easy to distribute work. Maybe I just like backlogs. With scrum you will need to get someone to be the product manager to talk about the features of the product. Version control is a must at probably should be implemented b4 even worrying about a software development process. I have worked in a company that started from 2 developers and went to 12 in a year. We started with no version control and low coding standards. The changes you will need to make will be gradual so don't worry about rushing to do a 180. Set a goal to change one thing a month and find supporters of your changes to make things go smooth.

Answer 9

As well as the recommedations of others I'd say that if you are tight on resources but have more say over how things get done you should make good use of off the shelf and open source products and libraries. This leverages the efforts of others, saving you time, ensures your code base doesn't become too esoteric and adds to your skillset so you don't end up being an expert in something that's useless everywhere else.