Pro Developer : Throwing Money Out the Window
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/cduncan/prodeveloperthrowingmoneyoutthewindow.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress) -
Glad to see another article by Chris Duncan. His insights into corporate survival are really useable, even though I want to gag every time I see that just about everything has turned into another marketing tactic.
-
That is actually the most realistic view of the corporate system I have seen in 16 years of contracting. Its too bad that its not easier to get everyone in line.
-
If programmers ran the company? Read Animal Farm by George Orwell.
Also, how many of the DOT COM start-ups WERE run by programmers, and before that the Silicon Valley start-ups? For every Bill Gates who succeeded, there is a Joe Bloggs who failed dismally.
My IT career can now be measured in decades and the one thing I have learnt that THE most important skill to learn is how to deal with people. Yes you have to be technically aware, but you will be nothing but a backroom boy if that is all that you are.
By definition, the people at the bottom of the corporate food chain DO see the minutae of the organistion. The won't see the external factors that concern people at the other end of the chain. All they can hope to do is to improve their particular section, get promoted etc.
At the top of the corporate ladder the CEO's aren't interested with the minutae, they have employees for that! You cannot steer a major company by watching the internal minutae, particularly as you have to be looking at external factors.
It is the role of the middle managers to inject some realism into the fantasies of senior management. The middle manager should have a grasp of the technicalities and timescales involved in a project. That said, they also need to have a foot in the other camp and be aware of the cost constraints and deadlines being imposed.
The more layers of management there are the less likely a technical constraint is going to be listened to.
To give a real example, I used to receive a 12Gb tape of a SQL6.5 database. I had to restore this tape, then transfer the data across onto a SQL7.0 box. I then had to run various processes to migrate this into a data warehouse. That 12Gb would result in 20Gb of data in the data warehouse.
If I got the tape at 08:00 then by 14:00 I could have the job done. This was with no contingency for SQL6.5 problems, heavy network traffic, dodgy tapes etc. In between 10:00 and 14:00 I would get upwards of 10 phone calls asking when the data would be available.
I even got a grilling from the CEO on one occassion because the data was needed for a client demonstration at 12:00!
Eventually, I got smart and told them that the sheer volume of data meant that only next days service could be achieved.
LESSON. Unless you are 100% confident, never give estimates in hours. Give estimates in days. Management will always try and truncate an estimate given in hours. For some reason they won't try and truncate and estimate of 1 day.
-
I have to agree with David.
Most programmers I have worked with, given free reign, would never finish a project. They would spend their time evaluating new toys and technology. They would never get a project beyond 90% complete before they saw or heard about some new technology that they would just have to learn and incorporate. If they ever did manage to get a system into production, it would be guaranteed to be completely different than any other system in place, and would only be compliable on their workstation because of some special tool that they installed.
In general, programmers need competent managers to make them successful. Without managers setting firm guidelines, they would not accomplish much useful work for their employers.
The only time they get over this handicap is when you put them in charge of other programmers. Then they get religion.
-
Hi
Good article. This is perhaps off track but....
In the world of chaos in which IT companies are well and truely in, it is critical that developers and associated management work to a strategic framework that allows them to provide differentiated value-add to the the market place (along with some higene capabilities to keep generally employeed); but at the same time embrace true business needs and wants (both latent and blatent) in which to apply these core capabilities.
Unfortunatly, developers fall in the trap of "thats cool, lets do it" (with continual change) and upper management are either sold by marketers or have a tunnel like syndrome of technology and business needs that fail to see over the horizon let along whats in their face.
Not with-standing the core enconomics (there are 5 enconomic factors btw) underpinning a solutions "yes" or "no"; many people fail to really understand some basic principals in strategic planning which, with its strategic imperitives, should be the key factors that drives all application development work and every other portion of the business, no matter what the company.
Business should embrace future thinking as a basic principal. This may be:
+ understanding that we live and breath in a value-network (VN)
++ that lives in a past/present, immediate and future environment
+++ in which we analyse and "brail" the future, looking for strange attractors
++++ that our business's core is a series of 1st principals, encapsulated by core
capabilities which we trade value in the VN
unless we are focused on a mapped (and revisited) future, which is driven by stragetic imperitives and their associated projects to remold our core capabilities, most projects will drag on, with perhaps some good wins here and there, but missing the boat all too many times...
People need to get a framework in place (at any level), that is driven through stategic leadership at all levels, and only then will developers and upper management really see the light of not only their own business, but the real business of the people they work for, taking your core capabilities naturally with it.
Cheers
Ck
P.S. I can write a paper on future based thinking if anyone is interested...
Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA" -
I both agree and disagree with David. He's absolutely correct about technical people not needing to be running the company. However, Even the highest CEO in the company had better realize that by not listening to his technical people, he's jeopardizing his company or income in some way. I have yet to see a situation where a technical person failed to address business needs after being informed of them, yet see on a daily basis managers failing to address technical needs after being informed of them. I have seen many many instances of technical people going to their manager and explaining a situation which would fail a project provided its not addressed, the manager ignored the discussion, then comes back a few weeks later asking why the project is failing. well, duh......what did they believe was going to happen, after being told of it. It may very well be that the middle level manager isn't communicating, or doesn't understand the issues, or doesn't have the time, but that's not the type of person you want managing your technical people to start with. Its a recipe for disaster. This is the direct responsibility of the person placing that manager in the position. The thing is, its not the responsibility of the technical guy at the bottom of the ladder to even have to deal with crap like that. Its his/her responsibility to provide technical direction and experience, not to mention the skillsets he/she was hired for, that will prevent costly mistakes.
True enough, we all have to be able to work with people, but to be honest, had I wanted those types of responsibilities, I would have chosen a different field for my career. Perhaps Manager. Its the manager's repsonsibility to provide resources and direction for his managed persons. The manager is there to facilitate the technical person doing what he was hired for. Notice that word facilitate. That means to make it happen. If the manager needs to better understand an issue to be able to do this, its not the technical person's responsibility to hunt him down, tell him he doesn't understand it, and tutor him. It's the manager's responsibility to indicate that he/she doesn't understand, and the technical guys responsibility to help him/her with the understanding and together creating a direction that accommodates both business and technical. Chris's article gives some excellent advice towards overcoming the shortcomings of manager's, and some direction on providing better understanding and communications with these corporate types, to overcome what I would term "Poor Management". The advice he offers is quite similar to what I've used in some situations over the years, and it works in a lot of instances. When it comes right down to it though, they would have no reason to use his advice if managers were really managers. In other words, they managed their resources efficiently. I would say that the very first part of being able to manage a resource, would to be to understand what that resource is, and how it should be used. Would anyone hire a programmer who couldn't program? Why then, do they hire managers who can't manage? This is where it gets interesting. They don't. They hire people who have a proven history of managing. Unfortunatly, they do not give consideration to WHAT is being managed. Managing an office, a pool of secretaries, a bunch of workers, almost anything you can think of, really cannot be compared to managing technical people. With any of them, the manager has a good chance of being more knowledgable than the employee. After all, its business processes they are dealing with. With technical people, its quite unreasonable to expect the manager to know as much as the techie. This leads to the areas of contention we see in the world. With the standard set of managed people, its generally not critical if they are ignored. With technical people, making this same judgement can cost the business severely.
Now that I've said that, let me ask a question. As a technical person, How many times has your manager sit and worked with you at your desk and for how long. Or, as a manager, how often do you spend time seeing what is involved in what your managed people do. Over my career, the greatest breakthroughs in communication have come from my manager sitting down at my desk and observing. In 16 years, I have had only a single manager who did not get up saying, "I had no idea it took all that." If I could find the company he is with today, I would do everything in my power to work for him again. It was the single smoothest IT department I've ever worked in. We had morning meetings, every day, to get and give direction and info for the day. Code reviews were standard on every piece of code to hit production, and when issues arose, it was discussed thouroughly until everyone had a clear picture of what was wrong, what direction we wanted to go, and the path best for the company to take.
-
Scorpion, your response seems to cover a lot of how things "should" work. What I like about this article, and the other one by Chris that I've read, is that they come in from a point of view of "forget how things 'should' work and let's deal with how things DO work".
As I'm reading this, it feels like I'm reading a copy of How to Win Friends and Influence People translated for the technical mind. And anyone who wants to become more than just a programmer (with all the income and bene's that come with that) should read that book too. Yeah, it sounds like a weird title, but the information in there is worth millions.
BTW, I agree with a lot of what David Poole had to add.
-
Man, I really love the discussions you guys have here, and I think AjarnMark really summed up my intent to not focus on how things should be, but rather on how to deal with the way things really are. It took me a long time to get to that point in my own career.
David, Tom and Scorpion also make a lot of good points. It's true, as Tom points out, that if programmers ran the farm, we'd probably never ship anything either, for completely different reasons. Deadlines and discipline are required to bring anything to completion. However, I frequently question how much discipline most middle management possesses. I think David's point is also pretty on the money that the more layers of management you have, the less likely techies will be heeded. I've worked in both huge and tiny shops and that's very much the case. And as for Scorpion's question about managers sitting at your desk, I find that to be directly proportional to the size of the company and the Dilbert factor.
ckempste also touches on something that I emphasize frequently. What he refers to as "future thinking" is analogous to a degree to my assertion that the root of all evil in the corporate world is shortsighted thinking, particularly in software development. While some of his bullet points sound a bit like Corporate-Speak (don't hurt me, please!
), the points are nonetheless valid. You should write the article you mentioned – we can use all the help we can get!Things have been so busy of late that I have to drop in and kind of batch process my comments, but I just wanted you guys to know how much I enjoy the interaction. I do a lot of tweaking to the seminars & training we do on based on what I hear from Real Programmers in the Real World. Nobody knows what really goes on out there like you guys do!
Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
http://www.showprogramming.com/TheCareerProgrammer.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress) -
Your absolutely correct, AjarnMark. Don't get me wrong though. I agree with a lot of what David had to say as well. I was certianly not saying that there was anything wrong with his opinion. I just believe that a different viewpoint to this is needed. I don't believe for a minute that its enough to look at what "IS". That's a firefighters viewpoint. I was very impressed with the article, but believe that it's VERY important to look at, and express opinions on, the "should be". Every trip begins with "IS", as its quite unavoidable. No trip goes anywhere until the "should" is applied. Treating symptoms will get you through in a pinch, and last until the next treatment. Treating the disease will releive the neccesity of the treatments.
Take any number of people and place them in any situation you can think of. Watch what happens. The situation will not change until one of them gets the idea for the "should". Even that's not enough though. The person seeing the should will now have to work to make it come about. The more people on board with the "should", the faster its changed to become the "is". The way you get people onboard with the should, is to express the idea that fixing the underlying issue would be a better approach. When David says:
The more layers of management there are the less likely a technical constraint is going to be listened to. , we need to realize that this is only true if we allow it to be. Now, I am not out to change the world, but I would be guilty of continuing the problem if I didn't at least express the need to look at it from this perspective.
-
quote:
Now, I am not out to change the world...Go for it, man - if we each change just a little piece of it, together we can hit a pretty big chunk!
Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
http://www.showprogramming.com/TheCareerProgrammer.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress) -
If it was that easy, I'd of done it by now.......LMAO
Hey, I know, if we all band together..........
I just realized you are the one who wrote the article to start with (I can be slow sometimes...). Anyway, kudos on the article, and as I said up above, it is the most realistic view I've ever seen, I was impressed. I'll be watching for more.
Edited by - scorpion_66 on 12/17/2002 4:05:13 PM
-
quote:
If it was that easy, I'd of done it by now.......LMAOHey, I know, if we all band together..........
And of course, we certainly don't mind your taking the point position.
Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
http://www.showprogramming.com/TheCareerProgrammer.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress) -
I'm far too outspoken to make a good leader. Besides that, isn't the point guy the one who takes the first bullet. (grin)
-
quote:
Besides that, isn't the point guy the one who takes the first bullet. (grin)Oh, my, really? (Stares innocently at the sky, whistles a nonchalant little tune...)
Chistopher Duncan
Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)
http://www.showprogramming.com/TheCareerProgrammer.asp
Chistopher Duncan
Author of (Apress) The Career Programmer
Unite the Tribes (Apress)
), the points are nonetheless valid. You should write the article you mentioned – we can use all the help we can get!
Viewing 15 posts - 1 through 15 (of 31 total)
You must be logged in to reply to this topic. Login to reply