Thanks for the nice post.

The man pictured in my home node (my Pop)* would agree with you 100% with an enthusiastic nod of the head and big smile. Preparation, having a well organized workspace and generally always putting yourself (and your team) in a position to succeed are all things he STILL repeats to me when we visit he and my mother on the weekends. Much like your shop teacher I'm sure, my father practiced what he preached as a mechanic, machinist and, now retired at 74*, the neighborhood mechanic. Admittedly he has proven far better at applying these rules than me but (hopefully) I have another 35+ years to catch up to him.

I've worked with and for people who have let their ego get in the way of successfully completing a project. We start with what would seem like a clear, well planned path only to have it derailed with "What if we did...". Usually all in an effort to stand out for upper management, clients, customers or driven by fear etc. 99.999% of the time it would lead to a badly blown deadline and poorly executed product with features that weren't in anyone's specs at the start.

Be well prepared, organized and ALWAYS put yourself and the people you work with in a position to succeed.

1. Yes I still call my father "Pop" and so does everyone else in our family. :)

2. He actually retired begrudgingly at 71 and was honestly ALWAYS the neighborhood mechanic for as long as I can remember.

Usually all in an effort to stand out for upper management, clients, customers or driven by fear etc. 99.999% of the time it would lead to a badly blown deadline and poorly executed product with features that weren't in anyone's specs at the start.

I've been a consultant and an in-house resource. There are different challenges in each context, but the single biggest factor I've seen is fear. The concept that "We can't say no to her" is probably the most destructive element in my experience.

(Nods...)   Somewhere I stumbled upon an article on:   How to give requirements to a programming team.   It was written specifically for upper management folks in non-computer related areas of an organization.   And one of the cautionary tales given was, basically, how not to be a “her.”

Outside of the immediate domain of computer hacking, the process of creating computer software is poorly understood, just as much as it is business-critical and extremely expensive.   Many folks in “her” position have realized ex post facto that they unintentionally caused a serious over-run by what they innocently said in an e-mail ... never intending to have done such a thing, but with incomplete understanding of what might happen next in the down-stream authority chains.   (I remember that the article also referred to the classic “whisper a message into the ear of the person next to you, and so-on around the room” communication problem.   And, perhaps slightly irreverently, “at the top of Mount Sinai, God was ‘merely talking to’ his good friend, Moses.   But that’s not how it looked from the valley floor.”)

Warmest regards of the season to your “Pop.”   May he live long and prosper ... and never really “retire.”   (In my experience, such folks never really do, and they are the gems of the earth.)

“Warmest regards of the season to your “Pop.” May he live long and prosper ... and never really “retire.” (In my experience, such folks never really do, and they are the gems of the earth.)”

Thank you. :)
I hope to reach that age and be able to not retire as well.

"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote

The first thing that they teach you is how to plan. You work out everything that you are going to do on paper first. You prepare a bill of materials. You work out step-by-step what you are going to do, how you are going to do it, and how you are going to know that you did it correctly before you go on to the next step.

Off course, by cleverly avoiding putting labels on it, it didn't trigger automated "don't do that" responses. ;-)

I didn’t use those buzzwords because I wasn’t referring to any “methodology.”   The task of writing computer software is not at all like hunting a jackalope, where you have to sneak up on the thing.   It is something that for a variety of reasons must be delivered in-stages and with a nimble, flexible approach.   And it is an extremely delicate contraption, as any machine would be if it had an unlimited number of “degrees of freedom” in its movements – which computer software basically does have.

You can be “nimble” and “deliberate” at the same time.   In fact, the more deliberate you are, the more nimble you can be.   I have seen “agility” in the manner of Ginger Rogers (“doing everything that Fred Astaire ever did, only backwards and in high heels”) ... and “agility” in the manner of a staggering drunk.   Both groups claimed to be practicing the latest thing.

“We develop our software using the XYZZY methodology!”   Unfortunately, you have to follow that with the question, “... and exactly what does that mean to you and your team?”   At some times, it is a characteristic of a process that is ticking along like a fine watch.   At other times, it is excuses.

If you're doing the plumbing for a house, you can determine specific requirements: master bath, guest bath, main floor powder room, kitchen, laundry.

Each has well known standard components; bathroom has a bath or shower, powder room doesn't, kitchen has a dishwasher but laundry doesn't.

Piping, elbows, etc are available in a small variety of materials and sizes, usually only those acceptable by local building codes.

Basically, it's a well-defined job, though there's always the opportunity for change as things start being installed and you try physically moving between fridge and stove.

Software projects are not well-defined. You not only assemble pieces into systems, you have to first create the systems and components and sub-components. Imagine if you had to create all your nails, screws, bolts, clamps, and make your own glue before you could assemble a cupboard.

As Occam said: Entia non sunt multiplicanda praeter necessitatem.

I respectfully dissent.   If a software project “is not (yet) well-defined,” then one has no business writing code for it.   It isn’t “a project” yet, at all.

You can figure out where to put the stove and the fridge ... and you’d better be careful to do just that, because the fridge needs 110v power but the stove is 220.   If you now want to go back and change your mind, you’re gonna have to call in the electrician, and re-do all of the tile (and buy more tile), and ... and ...   Oh yeah, and the vent-hood is going to have to be moved, which means that the layout of the entire second floor is going to have to be re-done ... and ... and ... And if we do that, we have to get the structure reinspected ... and ... and ...

Which is why you learn very quickly to make up your mind and stick to it whenever you are dealing with contractors!

But, yes ... stop and consider.   How many software-project cost overruns do occur because someone didn’t like where they put the stove?   It’s easy to see the physical implications of change to a physical structure.   You realize that you are playing dominoes.

Also...   let’s be less melodramatic here:   we don’t actually have a metal-forge out in the backyard, and no one is collecting iron ore to dump into a blast furnace in the basement.   We use a tremendous number of “stock components.” (CPAN is stuffed with them.)   We use toolkits of all kinds.   Sure, our contraptions are built of thousands of moving parts, instead of merely dozens.   But we do not start from scratch.

(Nods...)   And a person skilled in joinery can cut the piece with exactly an appropriate amount of selvage wood (so as not to unnecessarily waste wood on the stock piece), and can execute the finer-and-finer cuts until he arrives exactly at a joint that’s stronger than any nail.   What looks like trial-and-error, though, is anything but that.

BTW:   I know that I am not “preaching and teaching” here ... not to this esteemed community of developers, some of whom are responsible for some of the most-astonishing software I have ever seen (and know that I will never match).   I am ... meditating.   Thinking about the process.   That’s all.   That’s all.

I learned that construction is not really something that I do well. I hire contractors.

I guess, this is the key to understanding different situations. There are people that are good at one thing, and there are others that are good at other things. In ideal situation, to get something done one should assemble right people to do parts of work. Now, the question is, how often do we have "ideal" situations? Personally, I'm still looking for one. In real life, finding someone who will do reasonable planning within reasonable time and reasonable cost also requires to be good "finder". That is why, I guess, in real life people are trying to find workarounds for the "proper" way you have described. The way is indeed proper, but very often not applicable. IMHO.

I've encountered lots of reasonable people willing to do a good job that's well-planned, in a reasonable amount of time, at a reasonable cost.

The trouble seems to come from marketing and management people who promise customers 16,000 square foot palaces, then allocate four guys in three months with a budget of $200,000. They always seem to outrank the reasonable people, so unreasonable demands get made and the project is doomed to failure from the start. Six months later the team size has doubled, the budget has tripled, and we have a deliverable that most of the team is ashamed to have been involved with.

At least that's been what I've seen - the people in charge are either non-technical and have no idea what they're asking for and no knowledge that would let them figure what the proper time and resource allocations should be, or they're so worried about pressure from management that they make commitments that they know are probably not reasonably possible, or marketing promises the customer a gold-plated Rolls-Royce at a Hyundai price just to make the sale and the technical people get stuck trying to deliver (and get blamed if they can't).

Thank you for a wonderful post. I agree with you in principle. I just wish I ahd worked for more peopel who understood it and that it worked that way more than occasionally. Unfortunately the sernior management often sets requirments that are incompatible with the task at hand. Too often the programmer on the front line is left without the luxuary of good design or project management

As a result, saddly, I have spent most of my career fixing/completing/or redoing projects that were planned in depth to meet the requirements of one software engineering paradigm or another. Often my work had to be done much too much seat of the pants to suit me, as the decison makers panicked. I have had to rescue projects that were so OVER planned that they were documented to the interrupt level from preliminary specs for hardware that had never been seen. Software designed to the pseduo code level by 'software engineers' who had never been involved in any portion the design and implementation of a programming language (this project was to build a gas-oil pipeline control system) ... there was NO test code written. The spec wasn't even finished by the time the customer started court action. But it was detailed and in depth and all but worthless. While this was the worst I have seen it is not the only one by a large margin.

/me nods...

I, too, have had a very similar experience.   A whole series of them, actually ...

Made quite a bit of money from ’em, too!   (Still do.)

Me too for a long time, however I did discover that while being the local fire brigade/wizard was pretty cool, sooner or later your management will throw you into something where you are certain to get burned.

One of the problems with doing really great work is that all too often people expect more and more excellence (read miracles) and Murphy and the law of averages will catch up to you. Sadly after one or two of those less then miraculous performances, your fault or not, it doesn't matter how many miracles you delivered previously.

Misha/Michael - Russian student, grognard, bemused observer of humanity and self professed programmer with delusions of relevance

Yes, I am dating myself ...

school had a “Shop Class,”

...it actually was possible to fail a class...

sundialsvc4, it is quite possible to communicate effectively without frequent exaggerations

I cordially apologize if my tone and manner is not pleasing.   I say that sincerely.   I mean to offend no one.