Software Development optimize

10 classic mistakes that plague software development projects

When you combine project management pitfalls with software development challenges, you have a recipe for some big (but often preventable) problems.

Project management is never an exact science, but when you combine it with the vagaries of software development, you have a recipe for disaster. I have seen a fair number of common mistakes that project managers make when working with software development projects. Some of these mistakes are not exclusive to software development, but they are especially prevalent and damaging in that context.

1: The "pregnant woman" mistake

Fred Brooks illustrated a common project management mistake with his famous statement that just because one woman can have a baby in nine months does not mean that nine women can have a baby in one month. And we still see this come up time and time again -- the idea that throwing more people at a problem can make it be fixed quicker. Sadly, this is just not true.

Every person you add to a project adds friction to the project as well --  things like the time needed to bring them up to speed or coordinate their work with other people. In fact, my experience has been that there is a tipping point where adding people actually slows the work down more than it speeds things up, especially for the first few months. And there are many tasks that just can't be split up to be done by many people or teams at once. They simply have to be done "one foot in front of the other."

2: The wrong metrics

Managers need metrics for variety of reasons: measuring "success" or status, performance reviews and analysis, and so on. The mistake I see too often is that the easier it is to collect a metric, the more likely that it's not measuring anything useful. Of course, the easiest metrics to collect or understand are also the most likely to be used. Let's take "bug tickets" as an example.

It is easy to count how many tickets get entered. But that is not a good measure of quality, because how many of those tickets are user error or truly "features"? So managers often look to the next level of metric: ticket resolution rate (tickets closed per day or week or iteration or whatever). If you have ever dealt with a help desk that constantly closes tickets for things that aren't actually fixed, causing a proliferation of tickets, you know what it's like dealing with an organization driven by this metric!

Instead of actually getting work done or helping the user (for example, leaving tickets open until the user accepts the resolution), the organization exists solely to open as many tickets as possible and then close them as quickly as possible, so it can get its resolution rate up. A better number would be the hardest to measure: ratio of true "bug tickets" created in relationship to features deployed, changes made, or something similar. Needless to say, that is not an easy number to understand or to collect and report on. The result is that organizations choose to make decisions based on the wrong metrics rather than the right ones, due to convenience.

3: Estimating times too far out

A common problem I see with certain project management methodologies is that they like to play "just so stories" with timelines and time estimates. Project manager who honestly think they know what pieces of functionality any given developer will be working on more than a month or two out (unless it is a very large, broad piece of functionality) are likely to be disappointed and mistaken. Software development is just too unpredictable. Even if you can prevent or account for all the usual things that alter timelines and priorities, there is still little guarantee that things will take the time you think they will.

4: Estimating times too broadly

Another typical issue with time estimates involves not breaking tasks down into small enough pieces. If I'm told that a piece of work will take one week, I'll ask where exactly that number is coming from. Unless someone has analyzed all the minor pieces of work in the whole, a "one-week" time estimate is nothing but pure conjecture and should be disregarded.

5: Failing to account for tasks

How many times have you seen a deadline blown because it was established without accounting for a critical task like testing? That is another reason why you cannot and should not ever accept a task on a timeline that is not broken down into its component tasks. There is a chance that the estimate omits something important.

6: Poor communications

It is important to keep everyone in the loop on project status, but it is easy to forget to do it. This is where a lot of the mistrust between IT and the business team comes from: The business does not feel like it has a good handle on what's happening with its projects. And the more it feels left in the dark, the more likely it is to start trying to micromanage or force things to happen the way it feels it should be done. You can mitigate this problem by letting people know where things stand, both on a regular basis and when milestones are accomplished or the status changes.

7: Disconnected business priorities

There is often a wide gap between the priorities of projects within the development organization, the priority of the project in the view of the overall business, and the priority of the project in the eyes of the requester. A common issue is that a "high priority" project for one department is not viewed as important by the business because it does not generate revenues, and so the developers also downgrade it. Everyone needs to be on the same page with priorities, and a large part of that is to ensure that business units are not evaluated on the basis of projects that the overall business considers lower priority.

8: Constructing a wall of process

When the development team feels overwhelmed, one of the natural reactions is to establish a lot of process to slow things down. I have worked at places where even the most simple of changes required a change request form to be filled out (on paper, of course), in triplicate, physically disseminated, agreed upon, cross-signed by managers, and after all of that, there was still a 45-day minimum time until the work was to be done! Needless to say, this organization was not seen as a "partner" or an "important lever for getting work done" in the business, they were seen as a cost center and treated as such. The wall of process is typically a stopgap measure to deal with deeper issues in the process or company's culture, and while it is easier to put up the wall than to deal with those issues (and in some companies, the issues are irreconcilable), the wall of process is counterproductive and leads to a hostile environment.

9: The "hit-the-ground-running" myth

When adding people to a project, it is tempting to assume that they can hit the ground running. No one hits the ground running in the world of software development, and those who say they do are mistaken. Every project has an acclimation period, and the farther along the project is, the longer that acclimation period is -- there is more and more code to understand and get a handle on. Failing to take this into account will get you into hot water. It may take only a few days or weeks for a developer to come into the project at the beginning, but it could take months for a developer to be fully productive when added to the project long after it has started

10: Multi-tasking

This is another "skill" (like "hitting the ground running") that people think they have, but they really do not. The more you ask people to multi-task, the worse their work will be and the longer it will take. This applies to multi-tasking at the minute-to-minute level (juggling emails, phone calls, actual work, etc.) as well as the hour-to-hour or day-to-day level (handling multiple projects). The more you demand from people, the more the wheels fall off. To make it even worse, multi-tasking not only is likely to mangle the work, but it grinds people up and sends them looking for another job eventually... forcing you to bring in new people in the middle of a project and causing even more issues.

Other classic mistakes?

What other common issues have you seen derail software development projects? Share your thoughts with fellow TechRepublic members.

About

Justin James is the Lead Architect for Conigent.

59 comments
Treknology
Treknology

The first half of the project uses up 90% of the resources.

The second half uses up the other 90%.


If you really want a computer implementation to work properly, ensure that the people who write it also have to use it! The first major (like HUGE) database with which I was involved left the Data Entry Operators juggling at least six paper forms simultaneously because the people who designed the input screens hadn't even had the foresight to look at the source paperwork as a reference.


Does anyone remember that hideous "Chicago" font that screamed, "I have no idea how to use my Macintosh"?

ecommerece reviews
ecommerece reviews

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 reviews Thanks for sharing the information.

B_Dillon
B_Dillon

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.

jcllings
jcllings

Project owners and managers often don't get that almost every software project is an R&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.

herlizness
herlizness

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.

minstrelmike
minstrelmike

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.

Mike_Prince
Mike_Prince

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).

harry.kron
harry.kron

It's amazing how many of these common mistakes boil down to perceptions, or lack thereof, about the development process.

Mark Miller
Mark Miller

Related to your #10, I worked at a place where I "evolved" into a multi-tasking role. It's not something I asked for. It just became necessary, because we didn't have the right mix of staff to delegate everything that needed to get done. I got a new project manager, after having worked there for 2 years, who assumed I would follow a linear schedule, but that was impossible. He didn't observe or ask me about my work flow at all. He tried to impose one on me, but if I had followed it, some IT operations would've fallen apart. I tried to explain that to him, but he didn't listen to me. He tried to compensate for what I did by reassigning staff to do some of my "diversionary" tasks. My memory is it didn't alleviate my multi-tasking, and he just had to deal with it, or else we wouldn't have gotten anything done. Just a word to project managers. It's very disconcerting when the software team feels like what you want is out of sync with what they know needs to get done. Depending on the makeup of the organization, people may have found it necessary to multi-task just to keep the whole operation "up." If you're trying to change the work flow by adding/reassigning staff, it's going to take time to do that. "Hit the ground running" doesn't work in this situation at all, and creates disruptions to your entire operation if you insist on it. Related to your #5 and #6, another problem with large teams is they can miss *huge* tasks, especially if parts of the team are not allowed to communicate with each other, and/or there's dysfunctional communication among the staff (possibly caused by management practices). At this same company, with the same project manager, I discovered a critical task that was not scheduled, and no one was assigned, *two days* before a large system was going to be tested by a client. It resulted from a miscommunication between a software architect and another project manager, who worked under mine. My project manager tried to coordinate a fix for the situation, but did it badly, because he tried to assign blame. I think the reality was it was nobody's fault. The right hand simply didn't know what the left hand was doing. It was a systemic failure. We managed to pull it out, and it was a contractor who I hadn't even met before this who saved our ass. He had been using his experience and a design discipline in his code on the affected system, which enabled me to coordinate a technical solution that a team I assembled could implement quickly, which connected two systems together. It was still a close call, though. We were literally testing and debugging the system, including our "fix it quick!!!" fix, up until 5 minutes before the customer did their first test on it. It was surreal. I always thought those scenes in action movies where something big is gonna blow, the hero pulls it all together in the end with a team, yells "NOW!", someone presses a button, and the system that saves them all starts up, and works, were just fiction! The customer didn't notice any of the chaos, and that's the way it should be, though of course we would've all preferred if the chaos hadn't existed in the first place!

rmhesche
rmhesche

These ten points are pretty universal so they should be part of any business curriculum. Probably several times. Sales staff make promises for things we haven't done before, the engineers hand us a stick drawing and the technician figures out some way to make it work in a time frame that has no basis in reality. Only to have the spec change, usually more than once, the engineer draw another line and circle on the stick figure, and once again the tech has to make it work. I've worked on equipment for earth, water, sky and space and the 10 points are universal. Same song with a different tune. Why should anything with computers be any different? .

RMSx32767
RMSx32767

"Hitting the ground running" also plaques the hiring process. Companies want a new hire to be immediately productive with little, or no, knowledge of culture, procedures, processes, business flow, and/or who-possesses-what-knowledge-skills-and-tools. The next thing you know the new-guy (even a manager) is suggesting changes to processes he/she does not even understand. Great commentary on the myth-conception of "multi-tasking". I've also seen "responsibility creep". i.e. a new hire brought in to work on a specific task then diverted, for whatever reason, onto completely unrelated projects. Needless to say it likely spells DOOM for the original project and its schedule.

The Management consultant
The Management consultant

Refine the project outputs in very clear simple terms,the core resources needed,define the critical success factors,modulisation has worked in the past,as well as dependencies, and time lines.These all were not in place when Bill Gates tried to develope windows Vista.The project was simply saved when Bill was taken off the project.A lesson learned don't be too ambitious.If technical innovation risk is required as part of the project make sure it is tried and tested before building the project.

JimMcKeon
JimMcKeon

Great list - every item is very relevant, practical, and concise. Regarding #10 (MutliTasking): what's the difference (not so much in definition, but in impact) of being in a multi-disciplinary role (like yours) vs. multi-tasking?

rgalligher
rgalligher

Excellent article - these points, all valid, apply to everyone on the team - project manager, developers, business analysts, testers, product managers, etc.

TNewis
TNewis

As a SharePoint Architect I thoroughly appreciate this list. Unlike many of my colleagues who???ve have a strong development background, I???m more business focused; in more of an Engagement Management role to gather requirements and provide the initial translation to a high level solution design before the dev team gets involved. The point about communications is so important, and while criticism flies around as problems occur, is the responsibility if the business and the dev team to stay in touch, this process is much like a marriage; we all have to be on the same page. A clear deployment plan is also very important, as soon as the business gets their first taste of the solution the inevitable scope creep starts; ???oh, that???s cool, but can we???.??? But we???re still trying to bug fix. There so many aspects of SharePoint solution deployment that this list provides a great starting point to keep things in perspective. All too often the kick-off doesn???t set realistic expectations or there are misunderstandings that don???t surface until later in the project, so have a foundational checklist is always a good idea.

dimonic
dimonic

The mistake my company makes (for the 6th time since I have been here), is that it requests time estimates from developers, then routinely overrides them. People are essentially intimidated into giving time estimates that coincide with managements schedule, rather than based on the work to be done. Then we routinely overrun - usually to the "internal" time estimate and maybe a bit more, and morale suffers.

Slayer_
Slayer_

We do that now. Management solution to lower the bug count? Take 2 programmers and turn them into CSR's. Yeah, it reduced bug count, because there is less development going on. Now they are trying to figure out why work has slowed down.

Manasa Bharadhwaj
Manasa Bharadhwaj

Justin, is this a part of the software engineering myths mentioned in the book 'The Mythical Manmonth' written by Fred Brooks?

phil_simon
phil_simon

I hadn't heard of the pregnant woman mistake and wish that I had added that to my first book, Why New Systems Fail. Great list. Phil

Professor8
Professor8

Every project requires some experimentation. And I've never known anyone who was able to predict how many experiments would be required to develop a new way to do something, how many potential approaches and sub-approaches may be required in the mean time, and/or experiements to compare various ways by various metrics.

elmramir
elmramir

These are all great mistakes to mention, but changing requirements during the project build phase could be the most pernicious. Unless there is a substantial benefit, project leaders should push to add features at a latter phrase.

astevens009
astevens009

...12 years ago when I needed someone to affirm my observations that multitasking JUST DOESN'T WORK? :-) I'm from the school of thought that doing "one task at a time" allows us to focus on the task at hand and in so doing, we take more time to plan ("measure twice...") get it RIGHT ("...cut once") the first time through...

kci833
kci833

What happened to Requirements Management ? Does the author assume that 'ALL' requirements have been nailed down. I've seen some projects where the originator of a requirement changes it in midstream of the project taking it back to square one (time wasted). Agile, RUP, CMMI and other process improvement methods address requirements, but when the man with the money changes requirements, he then has to reach in his pocket and sometimes he doesn't like to do that !

ittechexec
ittechexec

Great post, Justin! I agree that all of these are major factors in why IT projects fail and why IT is often not viewed as a valued business partner and more of a necessary evil in the business. Here's blog post with some additional thoughts on IT project failure centered around the Business Analyst role. It's got a short, 1-question poll at the end, so please share your thoughts on it. Thanks! http://mdalums95.wordpress.com/2012/04/05/cio-it-career-project-management-how-to-plan-for-success/

Ole88
Ole88

If a PM or team manager can't say no, scope creep comes into play too often. You have to know when to say "yes" and when to say "no, that will wait for the next version or update."

reisen55
reisen55

Study SAIC and CITYTIME to learn everything about a totally botched project. And do not EVER send software development to India.

Ray Baker
Ray Baker

That's what I called number 1. It applies to all cases of project management. 20 years ago I too was against (leery) of multitasking, it doesn't work!

viggenboy
viggenboy

I seems to be especially the case working for the public sector, but the ever moving target, and/or flip-flopping of or specification of conflicting requirements has been the biggest bug-bear in over-running -projects I've been involved in. How many progress meetings have I endured the heads of two user departments bickering about their requirement being more important than the others, or the "that's not quite what we meant when we specified this".... "oh hang on yes we did".... "erm did we?"... "oh that was before we has the re-org, but now..." This is what leads to the process wall, as the bickering turns to mud-slinging in which the only place it sticks is on the development team.

26Alfred
26Alfred

A common hazard is taking too long a view, plan too far ahead and show no intermediate results to the end users. The result is a project that gradually looses credibility and support. The end users generally react negatively when (finally) results are shown to them. In a worst case scenario the goals to be achieved may have changed over time, rendering the project results partly or totally useless. Stick to incremental result delivery with a max event horizon of 4 to 6 months!

GrizzledGeezer
GrizzledGeezer

I'm told Microsoft does this, and it is surely not alone. It can be seen in the gradual deterioration of such products as Word and Visio. There should be no more than one or two people who make decisions about features and interface.

Bareng
Bareng

Not having a good induction plan (in the coding team) to introduce the new comer to the project e.g coding standards, code architecture and special components used in the software development process. This might be a resource consuming activity in short-term but it pays out in a long run

GrizzledGeezer
GrizzledGeezer

Point #1, about not throwing large numbers of workers into the pot, has another aspect that's often ignored. The more people working on a project, the less each is responsible for its success. This works against a sense of individual responsibility, and the resulting pride "in a job well-done". Workers should be added only as they are actually needed.

ktw.zd.net
ktw.zd.net

Very good post, very well thought. My favorite is #9 - nobody ever thinks about a person added to a project will need to be "trained" on that project, and also who will do it. The worst is interns, not that I don't like interns, but I slows you down when you have to teach and do at the same time.

neilson
neilson

Tech companies seem to have a special skill at failure to communicate. In my work as a software developer and tech writer I have observed several difficulties: - Failure to keep projects secret from competitors by failing to instruct developers on secrecy. In 1976, as a DEC customer, I encountered one of DEC's dev gurus at a party and asked him about the possibility of a 32-bit version of the PDP-11. I waved my hands describing two possible architectures, and may have mentioned Multics-style virtual memory. He said, "I know too much to say anything, but basically you are correct." Oops! If I knew about it, then everyone on three planets knew as well. My friend and the rest of DEC's VAX team should have been instructed to say, "Fascinating," and nothing more. - Failure to give secret knowledge to co-worker teams. Too many times I have seen the doc group get a request for documentation for a product just six weeks before its shipping date. Frequently the tech writer finds blocking bugs as she explores the product, and of course she gets blamed for the slippage. - Failure of management to listen to "the trenches." This is your classic Dilbert storyline, where management punishes messengers who try to get help for problems that the developers are encountering. An infrastructure to hide bad news from management develops. - Operation of hidden agendas. The folks in the trenches never find out until much later that their much-touted project was deliberately doomed for some nefarious purpose. The company's stock zooms and crashes on schedule, management's confederates make a bundle, and any whistle blowers are accused of paranoia. The best employees leave in disgust, management "restructures" the remainder, but cannot attract creativity while forcing it away, and bankruptcy follows. It's not all gloom. Occasionally things go well. Lessons from Moore, Brooks and Ershov are applied, excellent software and hardware go out the door, operation in the field is straightforward, IT crews are slightly happy, and customers are pleased.

Stormy7777
Stormy7777

read kci833's response and Justins also. Good article and a worthwhile set of "Ten things to consider before embarking on a software project..."

Mark Miller
Mark Miller

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, "You need to include that." I realized I was only including the parts I considered interesting, or necessary for technical integrity...

rmhesche
rmhesche

You're asking the difference between being skilled in different things, and switching between partly completed things. Multi discipline and multi tasking have nothing to do with the other, and if you wish to argue that, think of a heart surgeon who writes code, thats multi disciplinary. Now think of a heart surgeon who writes code writing code while performing open heart surgery. Thats multi tasking. I thought the difference would be obvious.

IAmFabulous
IAmFabulous

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, "When will it be ready?" 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 "If you press for a date, you will get a date. And not much else." I also included an anti-pattern in many official communications. The most common being "Weeks of coding can save days of planning." 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.

Justin James
Justin James

When you've got 10 spots, some stuff on a topic like this will get left out. :( Let's just say I could do a second article just like this, with no overlap... That said... if requirements change so much that you're "back to square one", there isn't much you can do about it. Either the initial requirement discovery was badly botched, or the business needs have changed so much that the original requirements are irrelevant. That's when "requirements management" can become code for "finishing a project that will be useless when it is finished, regardless of how well it was executed"... :( J.Ja

jcllings
jcllings

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.

Pragmatic Rich
Pragmatic Rich

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.

Frank-JH
Frank-JH

SAIC and CITYTIME do not even apply. That was fraud not a botched project for one of the reasons stated in the article. As for your last comment about India, what BS. Sound like you are worried about your job.

naresh_sn
naresh_sn

You seem to think folks in US / Europe are computers and not human beings... not even a single bug/error has ever crept in .right!!.come on...every one makes mistakes..i presume u must hv had bad experience..but that doesnt mean labelling entire country as bad..this is RACISM at its best !! Thank god we dont much people like you running IT.

Mark Miller
Mark Miller

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.

Bareng
Bareng

Ten years into programming. I agree with all your points

Mark Miller
Mark Miller

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, "Just install this, and you get X." 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, "How long will it take, and how much will it cost?" Saying, "It takes as long as it takes," 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), "The future has arrived. It's just not evenly distributed." That pretty well sums it up, though what that very perceptive person didn't say is "the future" doesn't really get to enjoy it, because "the present," which is a much wider swath of "the distribution" 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 "swiss army knives" (as a crude analogy) to solve problems. We try to take these "standard components" 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&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.

dogknees
dogknees

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.

Professor8
Professor8

It is a nationality. Now, the OP may be a nationalist, or he may be expressing his experience. I've had some professional fratsority brethren who were descended from people who had lived in India and, other than confusion over how to pronounce their names properly which you get between any 2 dialects or languages, they were OK folks, no problem with a sister marrying, retaining one of them to be my doctor once they got their MDs, to develop the weather forecast before my flight, etc. OTOH, I've had neighbors who were from India in the USA on H-1B visas, supposedly data-base experts, and they were totally clueless, based on attempts to make professional small-talk, so I can see that some such might have bad reputations when it comes to the quality of their work. And quite a few have trouble understanding and expressing themselves in colloquial American English. If anything, the one published criticism I've seen of SOME people on H-1Bs from India and recent immigrants from India, is that their educations relied too much on rote memorization. They may be able to correctly cite various aspects of programming standards, but seem to have trouble applying software development principles in practical settings. Former cross-border bodyshopper Vivek Wadhwa compared most STEM workers educated in India to having "static" knowledge, versus more "dynamic" application of concepts -- creative, innovative -- that is more common among US and UK educated STEM workers. Attending US or UK universities helps. It's only an issue because so many H-1B and L-1 (and equivalent) visas are issued to people from India, which does displace and drive down compensation for and disrupt careers of bright, capable, indusrious US and UK STEM workers. If reasonable numbers of such visas were give out, it would never be an issue; it wouldn't matter whether 99% of them were excellent or 99% of them totally incompetent. But people who believe they (and their friends and/or relatives) have been displaced by people who they see as less excellent, or whose work negatively affects the success of projects of which they are a part is irritating, so they lash out... with a broader and broader brush as the experience is repeated.

Tony Hopkinson
Tony Hopkinson

I agree with them all, so dfoes almost everybody else, yet you newbies :D 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

IAmFabulous
IAmFabulous

especially with the R&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.