I don’t see why Build system is so important. Can you even have a bad one? (MSBuild, Ant are fine) To me, it sounds like if you said having mouse with scroll wheel is important. Of course it is, but is not worth mentioning.
There are indeed a lot of reasons why software fail.
Based on my experience you have to have the right balance between:
-Management
-Employee
-Client
It seems that a very important role in software success is the communication on all level’s between these 3 factors.
Andreas
http://www.nueronic.com/
“I believe Struts1/ASP.NET/WPF/WWF/BizTalk/J2EE remains heavily deployed, despite its many flaws, in large part because it has widespread IDE support. I’ve even seen IDE support justify its use in a design”
I adjusted that statement a little.
Inv: Think automated continuous integration build system, like CruiseControl and the like. And it’s also very possible to have a decent build system (NAnt) but have it configured less than great.
They didn’t use an Agile programming methodology!!!
Why waste all this time with analysis that’s hardly ever necessary?
The question was “Will My Software Project Fail?”
Just answer “Yes”, and you’ll be right 90% of the time. This is a gold mine. Where else can you be right 90% of the time?
So, if we all use VisualStudio and TeamFoundation, we’ll have all of our software projects succeed? I’ve got a bridge in Brooklyn I’d love to sell you.
There is only one and truely one thing you need to know in order to make sure your software project succeeds:
- Do you know what the hell you’re doing?
Most of the time, the answer is “no”. Most projects have wide general concepts like “Integrating our quote tracking system with the news engine”, but not have no real clue on how they plan to do that. If they do succeed, it’s because somewhere along the way, they’ve stumbled into knowing what they are doing.
Take a look at most of the open source projects. Most use CVS and no built in IDE. Many didn’t even start out with any version control system before they came out with their first public release. However, the successful ones new what they wanted to accomplish, and had very specific ideas on how their project would work.
I found successful projects always start out fairly simple trying to get some very basic and standard features to work – just enough to start being useful. As time goes on, more features are then added to the framework, but in an organized manner. At times, the whole project will be examined, and decide if it is still heading in the right direction. Sometimes, basic bits and pieces of the project are rewritten from scratch, but rarely in a whole general rewrite.
One of the best projects I’ve ever worked on was written in a proprietary language with no version control or defect tracking system. We had a logbook where problems were written down and tracked. The president of our company knew exactly what he wanted, we had clear specs of what was expected out of the code, and we had a team of dedicated testers banging the hell out of it.
One of the worst projects I’ve worked on spent over $20,000,000 on the whole Rational suite of tools (and this was for five developers and two QA testers). They had a dozen designers and database engineers, but no idea what they wanted. This company burned money as every two or three weeks, the project lurched from one idea to another.
Having top flight developers, extensive development environments, the most integrated tool suite, or massive amounts of money cannot do anything for you if you cannot explain exactly what you are planing to accomplish.
Steve:
Another huge factor is that most companies do not have managers that manage the right things.
The vast majority of companies (even some that do nothing but make software) don’t understand two things:
- Software development management is a highly skilled specialty, with a whole field of study devoted to it.
- Most managers don’t even know the issues involved, nor have they any training on dealing with them.
Most programmers are trained to produce code, not develop a product. So if you don’t have a skilled manager to make sure other activities get done (documentation, testing, etc.) you are almost doomed to failure.
By the way, Jeff, another great article.
Steve:
Another huge factor is that most companies do not have managers that manage the right things.
The vast majority of companies (even some that do nothing but make software) don’t understand two things:
- Software development management is a highly skilled specialty, with a whole field of study devoted to it.
- Most managers don’t even know the issues involved, nor have they any training on dealing with them.
Most programmers are trained to produce code, not develop a product. So if you don’t have a skilled manager to make sure other activities get done (documentation, testing, etc.) you are almost doomed to failure.
By the way, Jeff, another great article.
Although this post’s topic matter has been covered well in the past, this is a good concise reminder… Once again glad I watch Coding Horror.
Scott: “I think the real problem lies in trying to convince people that the project already has failed. That it’s hard to maintain, doesn’t meet the functional requirements, and doesn’t make the end users life any easier.”
Man, Scott that hits quite a cord w /me my current situation. There are probably a lot more projects that your comment relates to than people want to admit. So, people should make sure they don’t miss it:)
Jeff,
Most of your readers are probably aware that the mistakes that cripple a project are made at the beginning of the project.
The most deadly are the invisible decisions . . . The things that do not get debated such as the version control, build system, and IDE.
Every project should be unique, in which case standard solutions should be questioned. The last project I completed I choose to write a set of very simple tiny scripts that built the project.
One very simple benefit was reclaiming screen real estate by not using an IDE.
110% in agreement:
I’ve blogged about this topic a while ago:
http://rubako.com/2007/05/23/estimation-art-or-science
Tnx for nice blog 
Hmm… I think methodology is far more important than tool choice. Of course brain-dead choices in version control and work/bug tracking will cripple you - but there are plenty of brain dead chocies that will sink you.
In fact any good methodology will incorporate handling bugs and work items and will require version control - but they are really incidental factors in my experience.
In fact, a focus on the tools points to a lack of a methodoloy IMHO…
“the version control system is a first order effect on software, along with two others - the build system and the bugtracker.”
Yup. That’s exactly why I put the chapter on SCM first in “Practical Development Environments”, and why that’s where I start when I’m talking to my consulting clients. In fact, the back of my business card says “Version Tracking, Build Systems, Bug Trackers”.
Sometimes I feel like the software equivalent of a good plumber 
I agree with the big three for sure, but I do think that an IDE (or lack thereof) can make a considerable impact on the day-to-day development. Consider writing C# code in Notepad versus Visual Studio.
That’s less of a problem than most people might think. An average software engineer tends to spend only about 10% of his time writing code. So you better shoot at optimizing the other 90% (like testing, debugging, getting the requirements right, all that stuff).
For me, pencil and paper are the tools of choice. Once you get the paperwork done, writing the code is, hmm, well, just boring. You know it’ll work. Of course, I’d miss syntax highlighting, it catches a lot of stupid typos. But apart from that - it doesn’t matter at all.
Or to put it bluntly: If you spend your whole working day at the computer staring at the code and putting a statement here and another there until you it somehow seems to work, you’re doing it wrong, anyway.
I will say that build engineering is probably the most challenging part of that trifecta. Work item tracking and even source control are fairly painless in comparison.
Build engineering is hard work. It’s a stone’s throw from real programming and requires substantial effort from at least one developer. And like all programming, it can be done badly-- so you have to be careful. That’s been my experience, anyway.
“Consider writing C# code in Notepad versus Visual Studio. Yes, that might be an extreme example, but I’ve worked in environments where crappy editors become bumps in the road that slow down the daily work and increase the number of “stupid” error that are otherwise caught by the smart IDE editor.”
Matthew, I agree - you should use the best environment you can. Aside from my bias that simplye says vcs/build/ are more important, there are two reasons I don’t elevate IDEs, First because editing environments are emotionally important and so personal, trying to standardise them will inevitably put people out. Second, not standardising on an IDE prevents developers from allowing the IDE to trump the build system, something I believe is quite common.
“That’s less of a problem than most people might think. An average software engineer tends to spend only about 10% of his time writing code. So you better shoot at optimizing the other 90% (like testing, debugging, getting the requirements right, all that stuff).”
Vinzent - so here’s an antipattern I think is real - powerful editing environments prop up poor solutions. I think this is true especially in the Java space, where tools like IDEA are ridiculously good, not just at refactoring but at browsing code - code that would otherwise just be scrapped. Case in point - I believe Struts1 remains heavily deployed, despite its many flaws, in large part because it has widespread IDE support. I’ve even seen IDE support justify its use in a design. IMO, I need to be eternally vigilant that I’m not allowing a complex, toxic design to live on just because I have a rad suit (pun intended) that lets me live with it.
“I think is far more important than tool choice.”
Michael, I doubt methodologies matter as much as we think - for example I’d say payment models trump methodology comfortably.
“In fact, a focus on the tools points to a lack of a methodoloy [sic] IMHO…”
In truth, I did think about methods (and IDEs when I wrote that) But my point was that if you don’t have those 3 things nailed, you’re hosed no matter what the method is. Methods assume the tooling fundamentals are in place.
How did the thread get this long without someone using the word “scope”? David W. all but says it – if the software development team and the consumer don’t agree very early on what the darn thing is supposed to do, and what it’s not supposed to do, project bloat and overruns will kill it. “Consumer”, by the way, doesn’t necessarily mean end-user – it could be the internal customer, the sales team, the company president, but there must be some identifiable entity with whom the development team can make its agreement.