Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234»»

Pro Developer : Throwing Money Out the Window Expand / Collapse
Author
Message
Posted Wednesday, December 18, 2002 12:48 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:36 AM
Points: 31,362, Visits: 15,823
Great article and interesting discussion.

ckempste, second vote for your article. Not entirely sure what you were leaning towards on the first post, but I'd be interested to hear more.

I've had management and tech jobs over the last 12 years and I've seen successful, implemented, and failed projects. While I mostly agree with things in the article, there are some things I've noticed that I wanted to comment on.

First, most projects I've seen don't fail in that they are not implemented. Usually they are late, or implemented and thrown out much sooner than expected. Maybe I've been lucky, but relatively few projects are actually funded with some $$ and never deployed. Perhaps that's the "I've invested in this, I can't throw it out" mentality, but that's been my experience.

So it seems most projects are only some % successful (10%, 90%, ?? not sure what the number is), but are often not well received. I think lots of this goes to many things, but mainly communication.

Developing software is hard. Not only for the programmers and architect/analyst, but also for the client. It's such an abstract thing that we often don't know what we want. Even I don't know. Until I see something, I can't completely visual what would work best (or better). I think this was and still is a huge problem in software. I've started to come around that we should only aim for, build, and budget for 60% of what we want and leave a blank check (time and money) for the 40% because we will modify things after that. I'm also a big "small modules and increments" kind of programmer.

So should I run the company and make the decisions? Not all of them for sure. I like being technical and worrying about my area. I don't want to worry about sales. That should be what the upper management ponders.

However the article and posts do point out some great problems here. We are human and we drive for our own adgenda. And that is where things break down. Executives worry about their reputation and their scorecard (salary) more than the long term health of the company. Does the stock price matter if the company is making money? A little since you do have an obligation to the shareholders. But also to the employees and company. And the short sighted, Q to Q mentaility leads to decisions that "throw money out the window".

Middle managers, technical and other, have different agendas. Furthering your career - Why take on a project what has a poor reward/risk ratio. Comfortable? Why rock the boat?, Bored? why make work for yourself?

I know I'm rambling, but the human factor is important. It's what gets in the way of efficient operation. Which is what us techies want, right?

Well, that gets in the way as well. I've worked with guys that engineered to death, missing the point that we have to finish. Worked with guys who'd rather play doom/quake/etc. and didn't test code. Seen code written that worked ok, but wasn't well engineered.

<gross generalization>The dot coms were mainly filled with techies that didn't understand business.</gross generalization> And they failed, but they also built some great technology.

That could have been used elsewhere and made money.

OK, I'm rambling so I'll drop off with my ideal view of corporate workings.

The company should exist to grow itself, care for it's employees, and better society. The profit motive should be there, but has to be tempered by looking at the place of the company in society. You do have an obligation to employees that includes the need to keep their interests (security, training, etc.) in balance with those of the shareholders. A code of ethics balances the executive goals with that of the company, employees, and shareholders, so that the Q-Q view of the world is not more important than the long term. Executives are not compensated out of line with other workers (and they are in the US). Emplyoees work for the good of themselves tempered with that of the company. Keep the total objective in line. You get paid, have security, etc. and you help the company grow itself for the long term.

Lastly, everyone respects each other, both as individuals and corporations.

Crazy, but throwing money out the window happens everywhere, not just in software. And it's not anyone's fault. It's everyone's fault.


Steve Jones
sjones@sqlservercentral.com
http://www.sqlservercentral.com/columnists/sjones







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #49595
Posted Wednesday, December 18, 2002 12:59 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Wednesday, June 30, 2004 8:52 AM
Points: 253, Visits: 1
I agree with those who realize that a great developer does not become a great manager. Those are two different creatures.

The problem is an assumption that to advance in career one needs to become a boss. In fact, one could make more money as a senior architect, designer, DBA, etc. or doing CONSULTING. Consulting is the way to go if you want growth. Consultants are the best workers. Employees (programmers) may leave at any time anyway. Consultant treats the company as a client that cannot be lost. Consultant won't ever leave you, just treat him well. Consultants are not protected against termination. They have to do a good job. The only challange for the manager is to realize the difference between a true professional and a hacker.




Post #49596
Posted Wednesday, December 18, 2002 2:01 PM


Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Sunday, April 13, 2014 11:06 AM
Points: 593, Visits: 26
It's interesting you bring up the money aspect of it, mromm. I've actually been denied raises before on the basis that it would cause me to be making more than my manager. I was told outright that in order for me to advance ANY farther within the company, I had to become a manager, and since I wasn't willing to do that, had to be happy right where I was.




Post #49597
Posted Wednesday, December 18, 2002 4:52 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:36 AM
Points: 31,362, Visits: 15,823
I've seen that too, though it's changing. More and more I'm seeing tech pros paid more than their manager. Comes a limit, however, since managing entails more responsibility at some point (arguable) and so worth more to the company.

Steve Jones
sjones@sqlservercentral.com
http://www.sqlservercentral.com/columnists/sjones







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #49598
Posted Thursday, December 19, 2002 2:05 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:58 PM
Points: 2,923, Visits: 1,872
Steve raises an interesting point.
quote:
People don't know what they want.


But they sure as hell know what they don't! Normally they demonstrate this after you've spent blood, sweat and tears delivering it!

One of the problems is the customer who thinks they are getting one thing, but actually asked (and signed the functional requirements spec) for something completely different.

I have an ancient uncle whose observations where that IT within a company goes through three itterations.
  • Know one knows what they want or what is possible so the project is a disappointment
  • Everyone thinks they know what went wrong last time or now has a pretty good idea of what IT can do so they ask for everything. The project overruns and is a disappointment.
  • Everyone is sadder and wiser and finally there is a meeting of minds within the vacumn of corporate thought.


OK there are variations on this but as a sweeping generalisation he is spot on.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #49599
Posted Thursday, December 19, 2002 2:08 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 12:58 PM
Points: 2,923, Visits: 1,872
Sorry about the spelling in the previous post. Some swine switched the office coffee for decaff.



LinkedIn Profile
Newbie on www.simple-talk.com
Post #49600
Posted Thursday, December 19, 2002 9:50 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 10:36 AM
Points: 31,362, Visits: 15,823
Was wondering about that post.

I think this is where what we do is more of an art than a science. Each work is unique (to a large extent) and works differently than other systems. As we give it to someone to use, they find different ways to use it and ask us to change it. It continually goes around like that as we modify, they react to our modifications and the circle continues.

My contention is you should expect this. We are dealing with a very malleable thing with software and when a client/customer/user wants to mold it, we should be ready and happy to continue to evolve it. Don't be upset, they are paying you to meet their needs. By being glad to meet their needs, you stand out and prove yourself as their developer of choice.

Steve Jones
sjones@sqlservercentral.com
http://www.sqlservercentral.com/columnists/sjones







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #49601
Posted Thursday, December 19, 2002 10:13 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, September 20, 2012 7:54 AM
Points: 21, Visits: 20
quote:

Some swine switched the office coffee for decaff.



Hang him!!! No, wait, hanging's too good for him. Make him the Maintenance Programmer!

Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
www.showprogramming.com/TheCareerProgrammer.asp


Chistopher Duncan

Author of
The Career Programmer (Apress)
www.PracticalUSA.com/TheCareerProgrammer.aspx
Unite the Tribes (Apress)
www.PracticalUSA.com/UniteTheTribes.aspx

Post #49602
Posted Thursday, December 19, 2002 10:22 AM


Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, September 20, 2012 7:54 AM
Points: 21, Visits: 20
quote:

<gross generalization>The dot coms were mainly filled with techies that didn't understand business.</gross generalization> And they failed, but they also built some great technology.



Yeah, that's something I try hard to make programmers realize. It doesn't matter how cool your technology is if the company doesn't make money. Why should you care? Ask the out of work programmers you know whose jobs evaporated after the dot com they worked for went out of business.

quote:

Crazy, but throwing money out the window happens everywhere, not just in software. And it's not anyone's fault. It's everyone's fault.



Very true. In fact, I'm planning on expanding both my writing and seminars over the next year to cover the corporate world in general for just this reason. No matter what you do for a living as a worker, productivity and corporate profitability depend on the very same issues.

Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
www.showprogramming.com/TheCareerProgrammer.asp


Chistopher Duncan

Author of
The Career Programmer (Apress)
www.PracticalUSA.com/TheCareerProgrammer.aspx
Unite the Tribes (Apress)
www.PracticalUSA.com/UniteTheTribes.aspx

Post #49603
Posted Friday, December 20, 2002 3:03 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, October 17, 2005 5:57 AM
Points: 33, Visits: 1
I agree with David and Tom. I have only 4 years experience, but I have seen major disasters caused by programmers who don't have any social skills and therefore cannot manage a project, and also from managers with no technical background who make idiotic, short-term fix / long-term disaster decisions.

The worst kind of managers are those who listen to their developers and then ignore them in favour of what has already been decided, or managers (usually techies) who believes in the utopian view of projects where no compromises or trade-offs need to be made, documentation is an optional extra, and everything will come good in the end because they are using the latest bleeding-edge technology which is sure to make everyone's life easier.

What is really needed is for utopian developers to gain some grounding in the real world and learn to make the often painful decisions that will have a reasonable chance of satisfying the customer and the project budget!

One final point. Learning to micro-manage your work will turn you into a micro-manager, and you will stifle creativity. Never schedule a task for less than a day. Personally, unless it is a very small project, I would not schedule a task for less than 5 days - if necessary other tasks should be rolled up into one larger task.



Post #49604
« Prev Topic | Next Topic »

Add to briefcase «««1234»»

Permissions Expand / Collapse