In how many good software project have you actually participated?

Question

Over my few (four) years in my career as a professional software developer, I've participated in very few good software projects. Most of the software projects I participated really suck: the design stinks, no unit testing, unclear requirements that changed all the time, poor management, lack of talented team, waterfall software development, ancient technologies and so on...

Talking with other software developers I found out that I'm not the only one in this situation, most of my peers are in the same situation. Discussing some forums and mailing list showed that most of the developers worldwide have the same problem.

We are developers and we love to craft software using the best techniques, methodologies and tools, but in reality that most of the software development market really sucks...

Are you actually working in a good software development project? Analyzing your career, how much % of you projects were good? How can we change it?

Answer 1

Even if the project sucks, are you doing the 'right' things on your part?

No unit testing? Install xUnit and test your code. No SCC? Install Subversion locally and put your code in a repository. Poor communication? Start sending your supervisor a 'plan' file every day or week so they know what you plan to do.

Many developers wait for change to come to an organization from the top-down. It may not always work, but if you start from the bottom-up, at least your own environment improves.

Answer 2

We can't until management changes.

Often we find ourselves in an industry where "If it compiles it's good enough" , so you're under constant pressure to put out code that's not the best.

Things like agile development is seen as "risky" by some management and they just want their old fashion waterfall approach.

It all comes back to management. Management hires bad coders, management assigns the wrong people as leads, management schedules too many useless meetings, etc etc.

All you can do is just deal with it and at the end of the day remember - it's not all that bad. We get to write software for a living, and last time I checked - that was a really sweet gig.

Answer 3

Some things in a project will be out of your control -- you can't do much about the quality of management or the clarity of the requirements you're initially given.

What you can do to make a project better is to do things the way you think they should be done. No unit tests? You can write unit tests for your code. Poor team communication? Talk people into using scrum for a week or so and see if you have less communication problems. In general, I have found that a lot of developers have personalities that are open to doing things a better way. That said, I've been lucky.

If you want to get all philosophical, you could say that what I'm getting at is to "be the change you want to see in the world", as applied to software development.

Answer 4

Well, as I see it there are two ways to go. Either you get used to it, or you act on it. I have been working with programming for 15 years in various organizations, and I would say that what we call management have not really gained a lot of understanding for how to create an environment for successful software projects during those years. It's up to you. When you join a team with bad working methods, actively strive to improve them. Share your knowlege, support your peers, discuss why a certain approach is better than another.

In my current project I introduced unit tests into the working methods of the team. To start with it was a bit frowned upon ("it's just a more code to write"). But then, as the upsides of the unit tests started to show, some team members actually started enjoying to create the tests, since it help them squash the bugs. Management will rarely bring such habits to your team.

Answer 5

Even if the project is bad, it is still your duty (some call it honour) as a developer, to do the best possible, or exit stage left ASAP.

We first need to stop calling all other code (read not written by me) crappy. Other code is not always crappy, it is sometimes hard to read. Yes a little more documentation could be nice. But if you are completely honest, is you documentation always up to date?

If you are writing the code, anything is perfectly clear. So you know that the function "ImportantFoo" connects the wobbly parts, and if you understands, anybody will. So, just for fun, take a piece of code you have written five or more years ago. (Professional code, produced with real deadlines). And try if you can understand anything. And if you can't understand the code, is the comment helpfull, if available.

Second everybody always complains, but almost never acts. So the situation can persist forever without any change for the best. If you start discussing code quality with your coworkers and you agree on some annoyances, please act. You can inform management and convice other coworkers, but the most important is that you should start doing it "as right as possible". Lead by example.

Most silver bullits, like unit tests, refactoring and pair programming are hard to understand first. They take more time at first so not everybody wants to understand their use. But you must sell them as an investment. And this investment pays of in the end.

Just as a coincidence, we just had a little meeting last week to discuss just this problem. And we found out we al had our little annoyances, but there where some common annoyances, and these need to be tackled first. And yes, it takes time, but this also is an investment that pays of in the end (or even sooner).

Morale: stop complaining, start improving.

Answer 6

One of the best software projects I was ever on was a government defense system. It had hundreds of pages of requirements, 70 engineers, 100 testers, 5 PMs and took two years to get our first build of the code out the door to QA. It was a painstaking process, because this was one of those systems that had to work. As a junior engineer, it was also incredibly boring given the fact that there's very little leeway for creative coding and design in such an environment (as it should be).

By contrast, I've worked on several successful commercial products that have shipped and are used by thousands of users and companies. Little if no design went into these products, and there were zero requirements. However, these products shipped and made our company money, despite the inevitable defects found by customers.

Which one was more successful? That depends on your definition. Clearly, the first example had the benefit of time and deep government pockets to devote resources to the project. It also had a very stringent process that marginalized the human element. On the other hand, I had great people working on those commercial products, and we succeeded despite the lack of process.

So, I guess I'd say the best projects have been those with either a) the best people or b) the best process. The very best will be the ones that maximize both variables.

Answer 7

I once worked on a rather large government project that had approximately 100 developers spread over about 20 subsystems. You would think it would have been a disaster, but it was the most successful project I have been part of so far. The people put a large emphasis on communication which helped alleviate many issues that could have arisen.

I think in a lot of cases projects fail due to a lack of communication. Whether it was someone who didn't speak up when a poor decision was being made or someone who did not fully communicate how long something would take to complete, it all comes down to being able to get information to those who need it.