October 25, 2007

Why do all Engineers Suck? Seriously I...

I work for a very large internet company is Palo Alto as a sr. project manager. I've done everything from waterfall to scrum. Giving engineers everything from more responsibility to less responsibility.

No matter what I do the engineers at my company miss deadlines and build buggy software. What ends up happening is we miss our launch date. Then after we finally get an update or product out the door, we spend weeks after launch fixing the bugs.

Why are there any bugs in the first place.
Are they engineers or not?

I'm extremely frustrated and looking for some guidance from the community. I'm seriously considering a career move outside of technology. What the heck are these college's teaching engineers anyways?

Tagged:

Comments

invsense: Bad attitude, which shouldn't be in the workplace. Why not ask, How can I improve my engineering team's efficiently or productivity?

Social Web

November 17, 2007

Posted by bretvh

5 stars ( 1 rating )

Having been on both sides of the equation as an web developer and a project manager, my first question for you is who is setting the deadlines? Are they realistic deadlines? I find that when engineers have some stake in setting their timelines (without external pressure to meet unrealistic ones), they are more apt to meet them. That being said, I have worked with several engineers who get their assignment, then drop off the face of the earth until they have good news to report -- whether it's on time or not. So the ultimate question, which I think other people have hinted at, is whether it's a management/process issue, or a personality issue.

Additionally, I am a firm believer that development engineers are different animals than QA engineers and depending on the scope or size of your project(s), you may need both. I don't believe that engineers should test their own software -- they subliminally know what will break it and will sidestep those steps without thinking about it. The only way to truly isolate bugs is to have a QA staff, or a subset of end-users, really flush out the bugs. Like it or not, bugs are a part of software development and bug-fixing is an iterative process, not something that magically happens. The more complex the software, the more potential for bugs to sneak through.

I can relate to your frustrations, but I don't think that it's all due to engineers sucking... there are often other causes for issues like the ones you are experiencing and sometimes it has nothing to do with the engineers. Remember, they are employees and trying to impress their bosses, too. A gentle reminder when they give you their estimates can help, i.e.,"did you account for xxx? or yyy?"

October 25, 2007

Posted by techVision

4 stars ( 3 ratings )

Sorry to hear you feel engineers suck. Engineers took us to the moon. Engineers built the Golden Gate Bridge. Engineers were the genius minds behind Google incredible search algorithm.

Perhaps your engineer aren't top notch. But, to fault them because there are bugs after launch is lunacy. Bugs are very where. And bugs are a normal process in the stage of development.

What is likely happening is poor planning. Not all engineers are good at estimating their tasks, especially when under pressure.

How much time are you allotting for testing? What is the percentage of time compared to the entire span of development.?

The last think you want to do is take your frustration out on the team. That will get you know where, your end up building a poor product and hurt your company.

October 25, 2007

Posted by catskul

4 stars ( 3 ratings )

Software is difficult. Just look at other major software companies, and how often they push back release dates and go over budget. You cannot simply assert how long some particular problem will take to solve. Its hard to predict the time/resources it will take for virtually all non-trivial software systems. How did you decide how long it "should" take? Doing large software projects is about managing risk, and that is a very complicated task.

First of all. You need to understand from the beginning that there *is* risk involved. An important way to find out how much and what risks there are is to learn how to get your engineers to talk honestly with you about *their* assessment of what the risks are. If they are afraid of your wrath, they will tell you what you want to hear: "Yes I can get that done in 3 weeks" What they wont tell you is: "But I will have to work double time and I will have to rush so much that it wont be done right". Even your engineers will often not know how long a sub-task will take. If they knew ever step needed to be taken before they started, the job would not be worth what software engineers are paid.

If you are not directly involved with your projects (i.e. coding along side your engineers) I suggest you find a respected leader among them and direct the team through the leader. No one can understand the trade-offs involved in what needs to be done right and what needs to be right-now on time without being directly involved in the development, and your engineers wont respect you if you try to.

In the end, managing a team of software engineers is an engineering task itself. You have to understand the basic concepts behind how software can succeed and fail, and you have to know your team well.

Comments

catskul: Take a look at:

http://www.inc.com/magazine/20071101/how-hard-could-it-be-five-easy-ways-to-fail.html

October 25, 2007

Posted by grantastic

3 stars ( 4 ratings )

I would be careful around your wording "suck." Is that really necessary? I do find it interesting how anyone can call themselves an engineer in an internet company.

To be a doctor you need to go to school. To be an engineer you can go to school and study engineering, or just call your self an engineer.

The label engineer should only legally allowed to be designated if you receive a degree. Just like for obtaining a Doctoral degree or PhD.

Perhaps that's the problem, your engineer's aren't formally trained?

Comments

DanielleR: Is it likely that a "large internet company in Palo Alto" would hire incompetent or untrained engineers, though?

October 25, 2007

Posted by DanielleR

3 stars ( 4 ratings )

People do their best work when they feel invested, proud of, and accountable for the work that they do. I If your engineers don't care about the products and software associated with their name, it's likely that they are not putting in the time and effort to make it high-quality. I think it's time to ask yourself why the engineers aren't devoting the time necessary to push a good product out the door. Do they feel unappreciated? Are they being recognized for the work that they do? Are they held accountable for their actions?

These are problems for which there are solutions. Morale can be raised, people can feel appreciated, etc. Maybe you even need to impose sanctions if the work is not up to your company's standards.

How do these issues relate to your team?

October 26, 2007

Posted by TunnelRat

3 stars ( 2 ratings )

As someone from both sides of the great programmer/manager divide, am starting to realize that maybe the poor reputation of I.T. managers is not very accurate. Some suck. Some suck more. Some are very, very good.

As for programmers, most are horrible people to work with, and especially, to manage.

For example, my current contract has me working in a cube on a floor that is primarily filled with salespeople, and I’ve noticed a few things.

They dress nicely.

They smile when they pass you in the hall – even if they don’t know you.

They banter, flirt, and generally engage in polite social mannerisms during the workday.

They hold the door open for you.

They say ‘excuse me.’

They are polite to coworkers and bosses.

They wash their hands after using the toilet.

Most programmers do none of these things.

OK, I’m sure the trolls are ready to flame me and say “If you weren’t such an jerk, people would be nice to you!”

But even the programmers I don’t know, the ones that work on different floors, that have no reason to think that I am an a-hole, share these common traits:

They are rude.

They dress poorly.

They are downright mean. Like “screw you, I can code” mean.

Just an observation, and I am probably over-generalizing. But I try to counter the stereotype by being somewhat polite, holding doors open for people, and whipping the anti-social sneer off of my face when I am not staring at the screen.

So for an IT manager, there is a huge hurdle that has absolutely nothing to do with technical competence that impedes their ability the get things done and successfully manage projects -- their staff are a-holes.

I sugest you stick to hiring former consultants or contractors. They hit the ground running. Oh, you will have to pay a lot more for them -- but they are 10 times more productive than the typical FTE in I.T.

Read my full rant <href="http://integrityconsulting.net/blog/2007/05/are-most-it-managers-bad-or-do-they.html">here</a>

Comments

TunnelRat: Yeah, I know, I screwed up the link. No everyone is going to say "He can't even code HTML!"

One more time:
here
bigBull: I'd like to add that sales people are extremely loud and should not be on the same floor as programmers.
catskul: Engineers in general are hard to work with. In some cases, some of the very things that make them hard to work with make them good engineers. Yet there are managers who do a wonderful job at it. Its fair to say that engineering management is a difficult job.

But just like any other job, its completely useless to blame the job for being hard.
CERulean: From my personal experience I have noticed that engineers and communication skills do not go hand in hand. What ends up happening is that the engineers who posses both Talent and Communication skills are promoted to a managerial type position very quickly in organizations.

November 17, 2007

Posted by codacoda

0 stars ( 0 ratings )

ok - so this is an area i'm pretty familiar with and i understand your frustrations although you could probably tone down your header a bit b/c i'm sure you know there are a hell of a lot of great engineers otherwise thee wouldn't an industry you're working for today... you have to look at it from a variety of angles.

if you want a top of the line engineer - you certainly want to pay up and you need to know how to collaborate with people who have strengths you don't have and areas of weakness where you shine. everyone needs 'em not everyone knows how to work with them. every industry has their divas and engineers can be the smartest intellectuals in the room but may not work under the same auspices as the rest of us.

it's like the sales people analogy someone gave here - great personality traits -but ask some of them to actually build something and you might get a great smile, a smooth response - but they won't be able to build it (don't get me wrong, sales teams are absolutely necessary and fundamental to make most businesses work well)

first - you have to have the following assumptions:

1. your firm is paying at or above market for the people
2. the people that are hiring actually know what the hell they're looking for and knwo how to do the due diligence to find out if they're hiring the 'right' person. you might have great senior project manager who makes great project plans but doesn't know how to hire staff. then you're screwed and it's not the engineers fault that they were hired... .the guy that seems to meet all those unrealistic deadlines brought on board a bunch of young guns that look great on paper but they might've been working with a great QA staff that rounded out their errors at their previous firm.
3. you don't find the right people that are in-house - go outside. why do you think people try to build this stuff to firms? so they have a finger that they can point out...they're BUYING accountability and to offset the higher cost they offshore. you find amazing talent that are at or below competitive market prices but they're hungry to perform above and beyond.
4. if you just can't deal - pack up and look at a different indsutry. if you're a very good project manager, you'll be paid top dollar in many industries. go to a consulting firm where they charge a good $300+ per hour just for that skill and you don't even need a law, dr, cpa , etc. degree to justify charging that amount (most of which goes to the firm but you'll be paid very wel).
5. if you think it might be the way you handle the teams - time to do some self reflection - we're all dealt @#%@# - those who handle those situations and thrive are the rockstars. those who simply complain, don't really change anything or themselves end up going on to another job where they find a new set of problems that leads them to justify that they can't meet their own deadlines....

good luck.