What single development processes can you not live without?

Question

I was recently brought into a company to help them define their overall software development processes. The company's team members were enthusiastic and very open to any practice as long as it would increase productivity and quality. Being a smaller shop, however, they really needed to watch their spending. This ultimately meant they needed easy-to-implement, light-weight, inexpensive options which would produce measurable, nearly-immediate results.

Two of my recommendations were the introduction of daily standing meetings to help with overall task management, priority/goal setting, general team communication and collaboration. I also suggested that they incorporate continuous integration as it lends itself to better source management, environment separation, unit testing, team communication, improved release processes and overall software development quality.

With consideration for the above constraints, what single development process would you recommend?

Answer 1

Ideally, this should be asking what SINGLE development process we can't live without... and then people could vote up the stuff they like or dislike.

Since it's open to broad answers, though, I'll give two :) For me, the single technology-based process I can't live without is source control. For people-related processes, it's team communication.

-- Kevin Fairchild

Answer 2

If we're talking software development lifecycle, it is requirements. I can see where you can just "jump" in and start coding if you're under pressure, but getting the requirements from the client and making sure they stick to those is crucial to make sure you're developing the right program and that scope creep doesn't inhibit the deadline, and everybody is familiar with what is actually being developed.

Answer 3

Daily stand-ups (really standing up, 15 min max), continuous integration, unit testing, automated builds

Answer 4

If I had to pick one, it would be close involvement of end-users. This in itself is more a principle than a process, but there are a number of processes which can help achieve it:

• Stories as used in XP
• JAD or similar rapid prototyping methods
• Flipchart modelling and prototyping

An approach we use with a lot of success is to involve the users in a domain modelling exercise. This lets them get their understanding of the domain into a data or object model, gives them some feeling of ownership of the product, and also lets us quickly generate a set of data manipulation forms as a first cut of the user interface. The sooner you can get end-users playing with your application, the sooner you'll get an clearer understanding of what they really need and be able to implement it.

It does take careful expectation management so that the users don't think the first-cut forms are the interface they are going to end up with. But if you handle that right, the dev team can win a lot of brownie points from the business users - both for involving them early, for delivering working functionality more quickly and ultimately for building a system that solves their problems better.

p.s. don't try to use this to avoid making analysis or design decisions yourself! You still need to be the responsible professional and make sure the users respect your expertise. But there are decisions which genuinely do sit on the user side of the fence and they should be encouraged to make them.

Answer 5

As @Kevin said, this should be asking what single process you can't live without. For me, it's decent source control. It underpins any development effort.

Answer 6

Single command build process. Running it should result in a distribution that can be installed and tested (installer, zip file, tgz file, ...).

Answer 7

20-30 min. maximum meetings. If people want to go over (or even better, meet with just their team member separately), sure, but set it up so that people know the required meeting will end in twenty minutes, that way you encourage concise discussion and the meeting won't drag on forever.

Reliable Source Control is a must, and everyone needs to know the protocols as to how your company uses it. A policy of not "Going Dark", as it's commonly phrased, should also be enforced.

Answer 8

Get a daily health check on your project - use a good source control system, get a continuous integration system to monitor your code and perform builds, and schedule daily (or more frequent) test runs. You do have automated tests?

Knowing that your software is broken as soon as possible is invaluable, it also helps people to keep quality in mind while developing.

Answer 9

All the advice given above is good. Source Control is the sign that software development is being done by professionals. The second sign, in my humble opinion, is that all development teams with more than two developers need at least a half-time testing person who is not one of the developers, and a public (web based) bug tracking system where the testing person has the ability to log bugs freely. It is better to have two developers and one testing person, than three developers who do their own testing, or one developer who is also the test person. Think of it as a necessary separation for reasons of probity, like the separation of the executive and legislative branches of a government.

But there are so many important things, the longer the time scale. Beta testing, field tests, customer feedback, accurate requirements gathering, everything really.

Often ignored parts of the development process can undermine otherwise solid efforts; Investing in the right tools to get the job done is important. Giving your developers time to learn new tools, new skills, new approaches is good. Insulating developers from things that drain their productivity to zero, and various aspects of Competent Management that have no metrics whatsoever, are all essential.

Warren P. Toronto canada

Answer 10

Definitely chocolate.

Answer 11

Daily Builds. Without them, I'd soon be lost in a morass of changes that would overwhelm even my second choice: source control.