views:

282

answers:

6

What is the most important thing to take care of when starting a software project? For instance, is it more important to have a handful good programmers that are highly team-minded or would you prefer the same number of uber-strong-skilled maverick programmers?

+4  A: 

There is no most important thing. There are tons of factors you should take into account. There is no silver bullet - each project should be analyzed separately to determine things required for success.

There are finance, human resources, requirements, customers and a hell of a lot of things to take care of. So one of the important thing is to have skilled people that can take care of these things instead of you :)

aku
+2  A: 

Get the team into the unittesting & design-for-test mentality from the start. Developers who can't/won't write unittests are either afraid their code isn't good enough to stand up to the stress, or didn't have a clear enough idea of what it was supposed to do in the first place. A strong base of unittests will give you the confidence to make major architecture/refactoring changes inevitably needed later in the project, and know you've not broken things. Unitests empower developers to work on code originated by another developer and know they've not broken it.

timday
from my practice it is tremendously hard (almost impossible I would say) task to teach people that never used TDD to write unit test :(
aku
also TDD wouldn't solve HR of financial problems :)
aku
I've programmed for years and years and my software has stood up perfectly well.. and TDD was barely used by anyone. Give up on the fad and concentrate on making software that passes system and integration tests instead.
gbjbaanb
A: 

there are a lot of issues you need to take account of, and many of them depend on your particular project but....

I'd say simple discipline, change control and some (minimal) standards. I've seen too many projects fail because a good idea was initially coded up (often by a single visionary developer), and then given to a team who couldn't decide what to put in next, how to move it forward, or just listened to every single 'can it do this please' customer suggestion. The end result was a project that splurged into a complete spaghetti mess.

It doesn't matter what kind of developers you have, just as long as they all pull together and the management ensures that the project becomes what it was intended to be, ie. keeps control of it at all times.

(now, go read Big Ball of Mud anti-pattern, and some of the DailyWTF posts for what 'rogue' programmers can do).

gbjbaanb
A: 

There are a number of factors that can make or break a project. The IMO most important ones:

  • Management support: if the project is part of an organization and there is not at least one manager who really understands the project's goals and considers them important, then your funding is dubious and you have no one to escalate problems to.
  • Requirements: you need to have a clear idea of what to achieve, or quick and direct communication channels to someone who can tell you, ideally someone who's actually going to use the software.
  • Realistic expectations and estimates: All too often, time and cost estimates are politically driven and impossible to meet right from the beginning.
Michael Borgwardt
+1  A: 

I don't know the exact context of your question, but I answer the question in the context of a company where you might/are working in. If you meant an open source project, then this might not apply.

The most important "thing" in a software project is the people who are involved:

  • Software development requires much social interaction. I haven't seen much great work done in isolation.
  • Most software projects somehow reflect some workflow processes, where people are involved. Again the meatware is in the middle of your attention. You need to talk with people who should work with the piece of software, to find out what they need.
  • Software systems have gained much complexity. Software engineering has become more and more a collaborative process.
  • Every practice like pair programming, unit testing or sticking to some rules depends on the peoples understanding, that it's important, and depends on the people's willingness to apply the practice in a good quality.
  • The companies "culture" is a good indicator for the environment of the people, who are involved in the project. Maybe it's the company's culture, that the boss is always right. Such an understanding ripples through the whole company. As a result, new people who will bring in fresh air, but will be quieted down very fast. Maybe it's the company's culture, that you can do very thing you want, but just get your work done. Then don't count on disciplined check-ins into the SVN repository or code documentation. The "culture" of a company gives you a good bird's eye view about the people in a company.

Look at the people, look at the culture of a company and make up your mind.

Theo Lenndorff
A: 

Read and use -> Code Complete, a practical handbook of software construction. By Steve McConnell, 2nd Edition or later.

Covers everything, under the sun, after the requirements definition and before the QA process. This is the only book that you will need outside the specific language programming documentation.

IMHO, the best book on how to create great software.

Roger