Inc. - Latest Comments in Thread

Re: Thread

Jim York — Fri, 03 Sep 2010 10:25:29 -0000

I believe you have identified many of the problems, yet it seems to me that the one most important factor in project failure is the lack of good requirements up front. Doing a Needs Analysis, identifying and prioritizing the critical success factors is essential for project completion. Yet how many programmers worry more about the "HOW" before they really understand the "WHAT?" I have taught over 500 classes on Software Testing and Quality Assurance and find that most of the errors detected by the testers could have been prevented if there was improved communication, involvement, and interaction with the client from the very beginning.

What do you think?

Jim York jyorknh@cjsysnh.com

Re: Thread

A_flj_ — Tue, 24 Aug 2010 05:23:39 -0000

I disagree only with no. 4. As long as you have a plan, a software design, and the team has developed common working habits and a common understanding of the project, reassigning tasks should be a breeze. I've seen it time and again, so I won't believe this can't happen.

There's only one scenario where reassigning tasks might be a problem: when you actually have no team, but just a bunch of programmers, of different skills and talent, thrown together by chance to make an app. However, in this scenario, your problems are probably a lot larger than those posed by reassigning tasks.

Re: Thread

vyengr — Fri, 09 Nov 2007 07:16:00 -0000

Would you consider implementing a service where we can get copies of this article sent to our "leaders" anonymously? I am currently on a 5 out of 5 project (all 5 failure reasons in play at once). While I am quietly singing the "Train Wreck Project Blues", all my bosses want to hear is "God Rest Ye Merry Gentlemen" / "Tidings of Comfort and Joy"

Re: Thread

Darrell Teague — Fri, 09 Nov 2007 03:11:00 -0000

There were a lot of comments regarding speculative claims lacking empirical evidence. The facts are that most large software projects fail (Jones, 1994, 2000). Developer productivity does vary by a factor of 1 to 10 (Jones, DeMarco, McConnell, etc). My own evidence after 20 years of doing software projects: Mediocre developers are not very productive and ultimately create more bugs than necessary. Conversely, stellar developers build incredible things and quickly (Google, Amazon, BlueNile, etc). Consider that a two-person team wrote a commerce engine that supports real-time trading of millions of dollars in transactions in eight weeks. A similar endeavor took a team of 30 mediocre folks a year to build a system that barely functions. So yes, agile is a best-practice, Joel is right and so are many others. Software engineering isn`t easy and frankly, if you have to build a bridge do you want the "A" team or the "C" students from the local university?

Re: Thread

End User — Wed, 07 Nov 2007 19:36:00 -0000

He forgot the biggest reason software fails. Nobody ever asks the end user what he or she really needs. The federal government is famous for spending gazillions on a new software project that only a few talking heads in Washington DC have any input on. After years of overages, programming catastrophes and bankrupt contractors that disappear into the night - the product is finally completed by somebody`s twelve year old kid and it is completely un-responsive to the needs of the end user. This is the oldest story in the book. Ask anybody that works for any federal government agency.

Re: Thread

Joe Gleinser — Sun, 04 Nov 2007 02:43:00 -0000

As a technology service provider I can support the argument that many projects fail. In fact I strongly recommend my SMB clients avoid custom designed software or even customized software. The payback to a $4 million per company will probably never justify a $150k investment and $50k per year in recurring costs. Even customized softare should be written with the expectation to throw it all away when the next retail version of the software is released.

http://gcs-tech.blogspot.com/

Re: Thread

Matt Warren — Fri, 02 Nov 2007 13:13:00 -0000

Building software is hard, Joel. Enter "Primal Development Methodology" in your favorite search engine and learn the truth.

Re: Thread

Jeff — Thu, 01 Nov 2007 20:45:00 -0000

It all depends on how you value your team. Mediocre is in the eyes of the beholder. For an alternative see role-based recruiting at
http://theschmitzer.blogspo...

Re: Thread

Molly — Thu, 01 Nov 2007 07:47:00 -0000

Just curious what everyone thinks. I have read the criticism about estimating your tasks, so my question is that is how does management get the info it needs to report on progress and a delivery date? The stakeholders (the ones paying for the project) have a vested interest in knowing this, and hearing that the artists are at work and they`ll let us know is not going to fly.

Re: Thread

Anthony Stevens — Sat, 27 Oct 2007 15:35:00 -0000

Joel has it both very right and very wrong.

Right:

40 hour (max) work weeks. I like what the previous commenter said about "bursts of inspiration", followed by comp time. You can`t burn your devs out and expect results.

Superstar developers. Imagine any other challenging field that requires intelligence, experience, and perspective, and hearing management say "We can get away with mediocre staff." Mediocre developers = mediocre (or worse) results.

Wrong:

Requiring developers to estimate out every nth detail to the sub-day level. This is just plain dumb, because by the time you get the estimates done the client has shifted the goalposts to reflect either (a) their new understanding of the capabilities of the software, or (b) their changing business environment, or (c) their modified budget, or (d) etc. etc. etc.

Joel has some crazy pathological aversion to agile software development methods, but they are sane and they work.

Re: Thread

Brad Gregory — Sat, 27 Oct 2007 05:30:00 -0000

I think that Paul Graham has hit the nail right on the head in his book, "Hackers and Painters", where he points out that software development is really a creative artistic process and not a precise scientific process.
Software developers are artists not scientists, and until this is really understood and managed as such, if "management" is really required, software development efforts will continue to "fail".
When you ask an artist to create a work of art, such as a sculpture or a painting, would you ask for a schedule? No. You would wait until the the artist believes he has finished.
I believe we need to shift towards the idea that software development is not something that can be controlled and managed precisely, but instead is an artistic process given freedom to `evolve` into a solution over a flexible time scale. i.e. think art and not science.

Re: Thread

Olga — Fri, 26 Oct 2007 10:15:00 -0000

All so true! I even sent it to my boss:) Speaking of creating software that somebody will want to buy – the concept/idea usually comes long before the actual development process – so it’s not what the article is about; and ‘not long lasting bad programmers’ somehow get enough time to do the job(!) that requires unbelievably long time to fix the mess:(

Re: Thread

Dan — Fri, 26 Oct 2007 08:18:00 -0000

Speaking of easy ways to fail: there`s an href on line 1452 of the source that`s incomplete and unclosed: :)

Re: Thread

Jamie — Thu, 25 Oct 2007 23:15:00 -0000

I think Joel is well off in wanting to have an entire team of superstar developers. Imagine the tedious arguments and the effort involved in managing all those egos. IMHO some of the guys who I have worked with that were the best programmers by themselves were hopeless at working in a team and meeting customer`s requirements.

This idea of having to breakup milestones into daily or hourly chunks also seems ludicrous to me. As an individual developer I often try and work out what I want to have done by the end of the day, but to manage this into some kind of project plan is not possible

Re: Thread

Evan Robinson — Thu, 25 Oct 2007 18:41:00 -0000

On average, Joel is dead right about 5 eight hour days for a 40 hour week. Check out "Why Crunch Mode Doesn`t Work: 6 Lessons" at the IGDA site at http://www.igda.org/article...

Re: Thread

Jeferson Spencer — Thu, 25 Oct 2007 18:37:00 -0000

Hi Joel.
A good opinion but I disagree with you when you talk about that the first mistake are mediocre team of developers because I dont`t understand what are a mediocre team for you.
I think that a mediocre team is a team that don`t want read, don`t want work, don`t want learn, don`t have atitude. If a developer have little bit technical knowledge but want to learn and have atitude it`s a very good developer and I want he in my team and he is not a mediocre developer.

Re: Thread

B Mack — Thu, 25 Oct 2007 17:02:00 -0000

Joel is an idiot who doesn`t practice what he preaches. "Don`t write your own programming language... but I use Wasabi" (what a stupid name by the way)

So which of these is the reason Copilot is a failure? Try logmein.com... it`s much better... and free!

Re: Thread

Patrick Brady — Thu, 25 Oct 2007 10:58:00 -0000

Joel,

How can you say that `...a bad team of developers tends to be the no. 1 cause of software project failures...`? Who says? I usually enjoy reading your articles but I have noticed that you tend to make these wild claims without including any reference to support your claims.

Failed software projects are usually never a result of any one single cause and blaming the large percentage of failed projects on an imaginary population of `bad developers` is both naive and irresponsible. In my experience bad developers are either fired or delegated to making coffee for the rest of the team. They usually don’t last long in any one organization and tend to bounce from one job to the next.

Re: Thread

AreaMan — Thu, 25 Oct 2007 10:45:00 -0000

Mr. Spolsky is partly right. Using old-fashioned management tends to fail on software projects. But there are other, more essential inputs:

1. You have to have a market. The coders who put together all the spreadsheets that competed with Microsoft Excel didn`t all fail technically. They ran into Microsoft`s marketing muscle.

For embedded code, it isn`t enough to have technical success. Somebody has to want to buy the airplane or telecomm gear you`ve made.

2. It helps greatly to have managers who know what they are doing. I`ve written code for people who turned out not to know what a computer really is, nor what software is. People like this drive projects over cliffs.

3. It helps greatly to have customers who know what they want. It is quite hard for computer users to get used to a new system, especially if the new system is just barely working. It is easy for them to throw an expensive system in the trash and blame the software. It is impossible for them to know if a product is going to start working for them next week, or never.

4. Sometimes it isn`t much of a cure to involve the users in the development; They have their own jobs to do and can`t spare the time to work on creating software.

5. Software developers themselves don`t know if they`re incompetent. I`ve taken over half-finished projects from other coders and found hard-working, diligent souls can produce an utter mess. And neither they nor their bosses had any idea how incompetent they were.

Re: Thread

Wang Chung Yoon — Thu, 25 Oct 2007 10:31:00 -0000

"It`s a marathon, not a sprint."

I find this comment funny, in the context of Agile software development. IMHO, it`s only a marathon if you look at it as such. I prefer to look at a project as a series of small sprints. In the end, you get the same output. The difference is that one is much less daunting to think about. Divide and Conquer.

Re: Thread

Bruce Goldstein — Thu, 25 Oct 2007 10:16:00 -0000

I agree with most of joel`s comments but think that if you are building software for a specific client (rather than as a product) than you really need to do iterative development with the client providing explicit feedback. I have yet to have a consulting style project work based on a fixed schedule, even with great requirements as the client sees it and goes "oh I said X but now that I can see and use the beta version I really meant Y".

Iterations should be planned out with early iterations having explicit project plans (like version 0.1) and later iterations just having milestones as explicit planning is a bit of a waste of time as it only would work if iteration 1 goes perfectly in terms of client response and it never does.

Bruce

Re: Thread

jz — Thu, 25 Oct 2007 10:12:00 -0000

who says winFS was a failure?

pretend you`re interviewing for a top position at m$, and the high-IQ question they ask you: "Define winFS as a success"

Re: Thread

Shirley Zhao — Thu, 25 Oct 2007 09:54:00 -0000

Totally disagree with the mediocre developer comments. It really depends on what types of project you are doing. The keypoint is there are projects that the best developers wouldn`t want to do, and you got to make the mediocre ones work. I`ve had experience being very critical on developer`s quality of work, but over the time I`ve also learned that there are ways to make mediocre ones do their job right.

Re: Thread

Mark — Thu, 25 Oct 2007 09:13:00 -0000

Joel is dead wrong about the 40 hour work week, 8 hour day being best. Developers work in great bursts of inspiration, enthusiasm, and effort. One week may be an 80 hours week, and very, very productive. But if a developer is burnt out, and not feeling inspired, they will not be productive, they should not be there filling a chair for 8 hours. They should be out riding a bike, or doing some hobby. These productive bursts can not and should not be scheduled a la the `death march`. `Comp time` is a good way to handle this unbalanced work schedule. He`s mostly right about the other things though.

Re: Thread

Jay Harrell — Thu, 25 Oct 2007 08:52:00 -0000

Joel first says: "When you ask developers for one, however, many of them will respond by creating a schedule that breaks pieces of the process into weeks."

Then Joel says: "but I do this cautiously and build an extra three weeks into the schedule for the incoming developer who`s learning the new code, and an extra week for the outgoing developer"

Come on, which is it? Could it be that software development naturally breaks down into week-long chunks? Certainly sounds that way from quote #2, else Joel would have added 15 days for the learning curve, which ends up sounding ridiculously precise. In my experience, single days (or hours) have far too much variability in their level of productivity to be useful measures, whereas weeks have much less variance. Hence, schedules in weeks are wrong less often. Requiring schedules in days or hours is just another form of Mistake #3.