<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on 10 classic mistakes that plague software development projects ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-391056/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-24T09:04:16-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[Thirty-five years into programming]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3676918]]></link>
        <description><![CDATA[I agree with them all, so dfoes almost everybody else, yet you newbies are still having to cope with same issues. Makes you wonder why none of them have been addressed doesn't it, or how people make money out of software anyway. I'd like to make it clear that I'm in no way linking the above two points....No Really]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3676918]]></guid>
        <dc:creator><![CDATA[Tony Hopkinson]]></dc:creator>
        <pubDate>Fri, 15 Jun 2012 09:55:23 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[What?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3676796]]></link>
        <description><![CDATA[Surely you don't trim the comments to fit the number 10! I'm amazed at how many things have exactly 10 causes or 5 rules.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3676796]]></guid>
        <dc:creator><![CDATA[dogknees]]></dc:creator>
        <pubDate>Fri, 15 Jun 2012 01:39:18 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[ecommerce reviews]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3676754]]></link>
        <description><![CDATA[Nice post! As i know that the everything is possible in the programming . No doubt, if someone change with the help of the nature , then it is only guess not give the exact location. So when you are starting to develop a software then you need to know the some information in which our software can do the some mistakes.  ecommerce reviewsThanks for sharing the information.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3676754]]></guid>
        <dc:creator><![CDATA[ecommerece reviews]]></dc:creator>
        <pubDate>Thu, 14 Jun 2012 16:39:39 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Ten years into programming. I agree with all your points]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3673738]]></link>
        <description><![CDATA[Ten years into programming. I agree with all your points]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3673738]]></guid>
        <dc:creator><![CDATA[Bareng]]></dc:creator>
        <pubDate>Mon, 04 Jun 2012 05:39:35 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[more thorough investigation ^^]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3673226]]></link>
        <description><![CDATA[read kci833's response and Justins also. Good article and a worthwhile set of &quot;Ten things to consider before embarking on a software project...&quot;]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3673226]]></guid>
        <dc:creator><![CDATA[Stormy7777]]></dc:creator>
        <pubDate>Thu, 31 May 2012 12:04:22 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[worry not!]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3664049]]></link>
        <description><![CDATA[They gave me bunsen burner! And I only have to spend half my time using it to make coffee!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3664049]]></guid>
        <dc:creator><![CDATA[andrew232006]]></dc:creator>
        <pubDate>Thu, 26 Apr 2012 07:13:45 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I agree...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3664030]]></link>
        <description><![CDATA[especially with the R&amp;D part. Too many projects have to start with creating a 'proof of concept', researching something unfamiliar because one may have to support some special device/hardware used by the client, or legacy platform or API etc.It's going to take a long time before we get to the level of civil engineering or even our namesake, architecture.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3664030]]></guid>
        <dc:creator><![CDATA[IAmFabulous]]></dc:creator>
        <pubDate>Thu, 26 Apr 2012 05:44:21 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Technology oversold]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663762]]></link>
        <description><![CDATA[I think the problem is that technology has long been oversold. Computing was thrust upon the business world more by necessity than by design. IT then gave people the mistaken impression that it made things easy, &quot;Just install this, and you get X.&quot; I think this has influenced the behavior of executives, perhaps to the point of thinking that accomplishing technical goals is a matter of configuration, not design and engineering. The reason managers want a date is what they understand is they are devoting a set of people to a set of tasks, and it's unproductive to load new tasks on them before they've finished doing the first set of tasks. They want to bring in new clients and new projects, but they have to be able to make promises to make sales, because customers will wonder, &quot;How long will it take, and how much will it cost?&quot; Saying, &quot;It takes as long as it takes,&quot; is not going to give them confidence that if they put down their money they'll get what they want.The dysfunction is driven, I've found, by ignorance, often all around, by degrees. I saw a quote earlier saying (I forget who said it), &quot;The future has arrived. It's just not evenly distributed.&quot; That pretty well sums it up, though what that very perceptive person didn't say is &quot;the future&quot; doesn't really get to enjoy it, because &quot;the present,&quot; which is a much wider swath of &quot;the distribution&quot; is holding the purse strings, and they call the shots. Some would think that education would help solve the problem, and in principle it would, but the reality of the education system, including at the college level, as it exists is *way* behind on this. That includes the disciplines of CS and SE.We have built up a culture that believes in using &quot;swiss army knives&quot; (as a crude analogy) to solve problems. We try to take these &quot;standard components&quot; and make them work together to create a functioning whole. It's worked well in some isolated cases for IT, but it very rarely works when it comes to software engineering. Yet we've kept on doing it for decades.The reality is, though there are people who deny this, we don't have a way of engineering software that is up to modern engineering standards. By this I mean if you compare software engineering to, say, civil engineering, the two are worlds apart in terms of how they think about projects. As someone else said on here, every software project is like an R&amp;D project. That's not how modern engineering works. What I wish the business community and the academic community would admit to is that this is the state of affairs, and some resources need to be devoted to finding some way of doing it that is better. A big part of that is changing expectations on both sides of the spectrum, and that's where I think we'll run into the most resistance. Business people need to understand that computing is a new form of literacy, and it's just as important to understand it as to understand how to read and write. Technical people need to understand that we don't have a science in computing, and we need one badly to support good engineering. Ironically, I think if we started on this, things would appear to get worse before they got better, because we'd start on a process of challenging a lot of long-held assumptions, but the long-run result would be a vast improvement over what we have now.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663762]]></guid>
        <dc:creator><![CDATA[Mark Miller]]></dc:creator>
        <pubDate>Wed, 25 Apr 2012 14:31:39 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Gotta include the overhead]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663771]]></link>
        <description><![CDATA[I remember running into this at one job. My project manager asked for estimates based on software modules that needed to be written/updated. So I came with estimates based on time to code and do unit tests. I didn't include, as you said, time for administration, and meetings. We discussed that once, and he told me, &quot;You need to include that.&quot; I realized I was only including the parts I considered interesting, or necessary for technical integrity...]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663771]]></guid>
        <dc:creator><![CDATA[Mark Miller]]></dc:creator>
        <pubDate>Wed, 25 Apr 2012 13:55:23 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Requirements, and Business Case]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663680]]></link>
        <description><![CDATA[I can't believe I got to the bottom of the comment threads without seeing a single mention of Requirements. Getting the requirements identified and documented accurately, having project sponsor and business buy-in of those requirements is an absolute essential to any project.My second key addition is the Business Case - how many projects have you seen proceed with a weak or with no business case. Projects with strong business cases can survive problems, projects with weak or with no business cases cannot.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663680]]></guid>
        <dc:creator><![CDATA[B_Dillon]]></dc:creator>
        <pubDate>Wed, 25 Apr 2012 07:38:52 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[totally agree]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663583]]></link>
        <description><![CDATA[I've recently worked on a project in which everyone was very eager to get a time estimate. I was quite understanding at first because they had just gone through an expensive 2 and half year failed project in which they didn't get what they had paid for in the end. At some point, they had thrown more developers to the project to try to expedite the process.After the first meetings to get requirements and to understand the scope of the project, I was asked on leaving, &quot;When will it be ready?&quot; I hadn't even had time to make sense of all the documents and notes I had taken. And I was pressed at every turn for a completion date, not for a milestone but for the entire project which isn't trivial.This created friction. I ended up saying that &quot;If you press for a date, you will get a date. And not much else.&quot; I also included an anti-pattern in many official communications. The most common being &quot;Weeks of coding can save days of planning.&quot;I have thus far been able to keep the hostility and intimidation away, but still people are eager to get a final completion date, and as you say these tend to get overridden. It's really a vicious cycle, one developer disappoints, the next isn't trusted, and ultimately is frustrated and forced to compromise on quality, feature count etc. just to meet a date that pleases management. In which case they may be disappointed by these compromises.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663583]]></guid>
        <dc:creator><![CDATA[IAmFabulous]]></dc:creator>
        <pubDate>Wed, 25 Apr 2012 02:57:36 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[These all boil down to a universal misunderstanding of the engineering proc]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663449]]></link>
        <description><![CDATA[Project owners and managers often don't get that almost every software project is an R&amp;D endeavor which means that no matter how much you want it, no matter how you threaten or cajole,  no matter who you fire or hire, it will take as long as it takes. The best one can do is inject predictability and consistency at every single opportunity you get. The entropy that occurs naturally within the system can also be managed within the system unless it is actually leaking in from the outside. Then it must be managed from the outside.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663449]]></guid>
        <dc:creator><![CDATA[jcllings]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 15:38:45 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[No means not yet]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663409]]></link>
        <description><![CDATA[You rarely need to say 'no' unless they insist on an immediate mid cycle change.  Even then you don't have to say 'no' when you can say 'OK but not yet'.  If the project owner doesn't like having to wait that long, then propose shorter cycles so that they don't have to.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663409]]></guid>
        <dc:creator><![CDATA[jcllings]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 14:41:32 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Impedance Mismatches]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663398]]></link>
        <description><![CDATA[First it must be said and it must be acknowledged that estimating time in software projects is a black art.  I have never seen anyone do it well and to pretend otherwise is pure folly.One of the big mistakes I see all the time is the failure to tailor methodology, metrics and PM to the scope of the project at hand. I don't know how many times I've seen teams working on relatively small line-of-business apps that have been treated as though they were working on *creating* the next version of the .NET framework rather than merely *using* the current one. What happens is that layers and layers of abstraction and administration are put in place that are not and will not ever be used for anything because the underlying business process is static.The related mistake is that more often than not all of these abstraction layers are poorly documented, if documented at all, with the result that a simple project (allegedly) designed for ease of maintenance is virtually impossible to maintain;  when new developers come in, ramp-up times for them are extremely long, frustration levels high and, if they are sufficiently aggressive, calls for large-scale rewrites become the order of the day.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663398]]></guid>
        <dc:creator><![CDATA[herlizness@...]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 10:55:59 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Bug tickets are stoopid]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663385]]></link>
        <description><![CDATA[In our system, we work closely with the users and they have never wanted any sorts of reports on bug fixes or numbers of phone calls or anything like that. They just want the system to work. Our masters above in the organization keep trying to push us onto some help desk mgmt software  but we get our users to resist.If the system is truly being fixed and training material is developed, then over time your total number of calls should go down but the average time per call should skyrocket.We try to avoid separation of helpdesk personnel and developers so everyone has a vested stake in a working system, not a broken system. Note that a helpdesk measured by volume of calls has a vested stake in a poorly-working system.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663385]]></guid>
        <dc:creator><![CDATA[minstrelmike@...]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 10:14:58 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Absolutely!]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663337]]></link>
        <description><![CDATA[Scope creep/creeping requirements are one of my bug bears. PMs need to learn to say no in the right way to directors and important customers or the integrity of the whole development process is compromised. This  will eventually affect the quality of the product and later the companys image in the eyes of the customer. A PM or development manager that knows how to get this concept across to directors in an affective way is worth his weight in gold.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663337]]></guid>
        <dc:creator><![CDATA[Pragmatic Rich]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 09:11:23 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Hours estimate != Duration]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663308]]></link>
        <description><![CDATA[Maybe it's just me, but it's happened to me more than once...Knowing the products we make and having good requirements for a project, I feel I can make a good estimate hours estimate for a project. However, the project manager seems to think that an estimate of 120 hours will mean the job will be done in three weeks. While I, like many, work more than 40 hours a week, the 120 hours is the time I will be billing the project, not including admin time (manditory department meetings) or support time (since we support our own products).The project manager for the above 120 hour project was flabbergasted that I told him the development for the project would probably wrap up in four months, not in three weeks. (To note: We were going through a department restructure as well as coming up to a busy support season at the time).]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663308]]></guid>
        <dc:creator><![CDATA[Mike_Prince@...]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 07:53:21 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[It's all about perception]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663303]]></link>
        <description><![CDATA[It's amazing how many of these common mistakes boil down to perceptions, or lack thereof, about the development process.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663303]]></guid>
        <dc:creator><![CDATA[harry.kron@...]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 07:14:19 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Re Trying to boil the ocean ...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663238]]></link>
        <description><![CDATA[It's called global warming  But this is indeed a major issue with some projects, and they tend to grow accordingly too.  If you don't have a project leader who has a strong backbone then, you get a never finishing project until it's trashed.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663238]]></guid>
        <dc:creator><![CDATA[Spike_Needle]]></dc:creator>
        <pubDate>Tue, 24 Apr 2012 03:03:19 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[&quot;add new people as needed&quot;]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663221]]></link>
        <description><![CDATA[That's not possible, because when you bring new people on, they need to get up to speed. If you only add them when you need them, your needs are not going to be met for quite a while. Yes, too many cooks spoil the broth, but it's also a matter of *when* you bring them in. This is the reason that SE has tried to work out methods for estimating the size of projects, so that organizations can see in advance how many developers they will need for it *before* they need them.Small teams make for better projects. When I took SE in college, a kind of universal rule was you should try to keep your team down to 3-4 people at most. Any more than that and the communication overhead really puts a crimp on your productivity.I once worked at a place that had for a time a team of 6 (including me) working on the same project. I was brought in in the midst of the project. One thing I noticed which I had not seen before was duplicate code. There were a few instances where different people had written code to do exactly the same thing, but they wrote their code in different modules. They didn't copy-and-paste it. They had written each version themselves. I was tasked with doing some refactoring, and I took out this duplication. Again, lack of communication.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-391056-3663221]]></guid>
        <dc:creator><![CDATA[Mark Miller]]></dc:creator>
        <pubDate>Mon, 23 Apr 2012 23:36:53 -0700</pubDate>
    </item>
    </channel>
</rss>

