Apps

Software developers, are you an optimist or a pessimist?

Chip Camden discusses the differences he has seen in newbie and veteran developers in terms of optimism and pessimism. He also explains why he why thinks developers should have a healthy dose of optimism and pessimism.

 

Over in the CodeProject's Lounge, Edgar Prieto asks whether software developers "should have a positive or negative state of mind," by which he seems to mean, should they be optimists or pessimists?

Optimism seems to have one big thing going for it: confidence. The belief that you can tackle any problem, and even enjoy doing it, is central to being able to continue to work in IT. Without the ability to turn a blind eye to all of the unknowns and undecideds that you will face along the way and focus solely on a simplistic view of your planned implementation, you can't ever roll up your sleeves and start getting things done. Without the ability to turn off the naysayers in your mind, you'd become defeated before you ever began any nontrivial project. You need to have faith in your ability to overcome those obstacles when they arrive.

I often observe an unrealistic optimism as a prominent personality trait of young, energetic programmers. They usually hold onto that trait, even after several spectacular crash-and-burn project failures that could be directly linked to overly optimistic estimates and an inability to consider all aspects of the problem in their original design. These young bloods remind me of Spartan warriors, who would rather die in the pursuit of glory and honor than shy away from any battle -- no matter how insurmountable the odds. But if their careers survive these failures and they eventually learn from them, then they often go on to become great developers.

More experienced developers tend to be a little more pessimistic. They actively look for flaws in their design, and they've come to expect that what the client requests is not really what they want. They also know that, no matter how well they investigate the problem, something (or some things) will go wrong along the way. As a result, they've learned to be a little outrageous in their estimates because what seems excessive at the beginning of the project will seem quite reasonable (or even insufficient) by the end.

But you can also take pessimism too far. I once knew an experienced developer who always investigated every unknown and charted out every execution path in the programs he wrote. He almost never had a bug -- but he almost never got anything done. His colleagues would finish five projects (and fix all the bugs they introduced in the process) before he could complete even one of his near-perfect creations. He was the poster child for "Worse is better."

Excessive pessimism can also lead to an interminable design phase, as you try to answer every question definitively. You involve as many interested parties as you can, which often produces design by committee. As Hermann Hesse said, "If you talk about it, even the simplest thing becomes complex and incomprehensible." So you have to know when to say "good enough" and get started, with the understanding that you'll undoubtedly need to ask more questions later.

As you can probably tell by now, my answer to Edgar's question is "a healthy dose of both, please." You need optimism to help you take that first step in the journey of a thousand miles, but you need a healthy pessimism to keep your eyes open for problems before they get out of hand. So you should be optimistic about some things and pessimistic about others. The secret is knowing which is which.

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

37 comments
oldbaritone
oldbaritone

I always start with a can-do attitude, but I've learned that users can make a mess of anything! In that pessimistic spirit, I've learned never to "assume" that "if it's not yes, it must be no" - I've been burned too many times! Instead, "if yes ... | if no ... | else ..." The creativity of idiots can be amazing... :-)

LLL3
LLL3

Great column, as always. I believe the programming I do (mostly VBA for Word) is much "simpler" in nature than what many of you commenting do. Different operating systems, networks, browsers -- don't really affect me (well, Vista is a little scary...) But my experience has been that I'm actually more optimistic as I gain confidence through experience because I've learned there is ALWAYS an answer (so far) - or at least an acceptable work around. On the pessimistic side I have DEFINITELY learned the voice in my head that asks "how hard could it be?" needs to have its time estimates multiplied by 5 to 10! And when you say "the client requests is not really what they want" I say "AMEN to THAT!" So now I approach the project knowing that until they start using it they won't really know what they want but it's faster to get something in front of them and let them start using it and then happily (and hopefully quickly) adjust it for them, than to try to predict every single possibility in advance. But if I worked for a company that requested code and then never implemented it -- that would suck the wind out of my sails. (Unless they paid me a whole lot!) Sometimes when I make something very complex and later realize something simpler is better, it's VERY hard to let go of the complex creation.

david.kolb
david.kolb

We are all pessimists. Those of us who call themselves optimists are just pessimists without enough experience.

Jaqui
Jaqui

It can be done, but is it worth the effort and expense to save 20 minutes labour [ to borrow Justin's example ] Oh, you want this, this, this, that, those and these in the app? You know that each one of these requirements is x weeks developer time, before you even start testing and debugging? and documenting everything is the same amount of time it takes to code it.

Sterling chip Camden
Sterling chip Camden

... since the power has been out here ten times over the last week. Anybody else snowed in?

Sterling chip Camden
Sterling chip Camden

They leave it until the end, and then it never gets done. But the cost of no documentation can be far higher.

Slayer_
Slayer_

And I don't think there has ever been a snow caused powerout where I live. At work there has been maybe 1 powerout that wasn't just a useless breaker setup. We all went home that day :).

Jaqui
Jaqui

naw, only 2 feet of it here. which means yup, I'm not going outdoors, my knees can't handle the strain of more than an inch on the crap. only one power failure here, and that cause a main fuse for the building blew out. :D

Justin James
Justin James

I find myself becoming more pessimistic too. I've been involved with so few successful software projects. I think that less than 25% of the code I've written in my life has been deployed into production. The worst part is, most of the failures were non-technical (we're all familiar with that laundry list). I had one project to turn a 3 page paper form into an online form take 9 months, with the code 99% written and just waiting for final approval/tweaks because there were so many "stakeholders" in the paper form that I could only get them in the same room once every 4 - 6 weeks, and one of them wanted to change the process and the others didn't, and the stupid "hazardous material shipping form" was being escalated to high levels of one of the top 3 pharmeceutical companies in the world. Last I heard, 3 years later, that program still had not had the final 1% of the code written. My pessimism has served me well, though. For example, I almost never miss a deadline that I set, since I am so familiar with the gap between perceived difficulty and actual difficulty. I've also killed a ton of projects at birth, simply because I knew that they were bad projects... better to let a manual chore be wasteful by 10 minutes a week for 2 employees at $7/hour, than to spend 10 weeks of my time automating it, then retraining people, and then needing to maintain code. At the same time, I stay optimistic in attitude as much as possible. No one needs a "Negative Nancy" in their office. No one likes to hear "that's impossible, end of story" all of the time. The "it works, that's good enough" attitude is a great way to delivery mediocrity. Indeed, my skepticism on projects is my way of saving my resources for projects that will really matter. "Skepticism" is the best description of how I try to see things, I think. I've been around the block enough times to know the risks, but I still like the neighborhood. :) It's in the 60's right now here, BTW. ;) It was 25 or so two nights ago, which was astounding for SC. It's snowed less than 3 inches total since I moved here in 2002. J.Ja

joeller
joeller

I came into a ongoing website project whose first iteration was 7 years old. 1700 pages of code; not one page of documentation since the project was first initiated; and maybe three comments in the whole application. I was then supposed to read all 1700 pages of code to figure where the change I needed to make had to be placed?!!! After cursing my way through that project I swore no other programmer would have to go through what I just did, so since then I made sure I put in sufficient comments to explain where I'm going. I also came up with the idea of maintaining a change history on each page (an idea I got from a MSDN article about stored procedures.) This was to let future programmers know what had been changed and why. (One of the problems I was running into was changes that were made from apparently perfectly working code to something that didn't work. Knowing why would have helped figure out why the change had been needed and why it no longer worked.)

Tony Hopkinson
Tony Hopkinson

spread out over the life time of the software. Not in the plan, not in the budget, so wave it goodbye. It's one of the reasons I get really upset when developers blow their own feet off, through lack of decent standards, naming, even useful comments. :p 30 seconds now, saves someone three hours, six months later.

Jaqui
Jaqui

I posted that link to a good set of templates in it's own discussion.

joeller
joeller

I wish we did have snow. We finishing up getting 2 inches of rain at 34 degrees. Nothing worse than a cold wet rain. We are starting our third year without an significant snowfall (more than 1/2 inch) although supposedly the average is 24 inches per year. Biggest problem in recent times has been Ice storms. Then the power can go out for a week or more. And with most locations dependent on wells with electric pumps for their water supply, .... Despite the lack of snow though we keep having 2 to 5 power failures a week on base here even without any weather issues. I'm growing tired of the beeping of UPS's. I think our company has reached a good compromise between spending time over designing a solution and jumping in and supposedly using the agile model kick something out overnight that will then need to be modified to work properly. My boss says "we can do this in two weeks". Then I say "are you nuts?!!!" Then we work together to establish a compromise deadline.

Sterling chip Camden
Sterling chip Camden

Ours are hung from pole to pole beside the 100+ ft cedars and hemlocks, as if to taunt them into throwing down their branches. But the power company is talking about burying the line -- we'll see how soon talk turns to action.

Sterling chip Camden
Sterling chip Camden

"One has been a bad spectator of life if one has not also seen the hand that in a considerate fashion -- kills." -- Nietzsche, Beyond Good and Evil, 69.

Tony Hopkinson
Tony Hopkinson

I still firmly believe I can program anything I understand as well as I understand it. :D My pessimism, shows up when I'm considering whether I'll be allowed to.....

Tony Hopkinson
Tony Hopkinson

You have to be really careful in some operations. SS has a major problem in terms of working off line in that it will not tell you if you are checking in over the top of a subsequent version. Caught us out a few times that. It also doesn't work too well with file paths. It's easy to end up with working directories which look like thay have the same route all over your drive. Most annoyingly if your developers have different preferences on how to integrate with SS (auto check out for instance), it can on occasion make a complete arse of your settings. Keep talking about moving us to TFS at our place, hasn't got past that stage yet, though.

joeller
joeller

Which is why I install source safe on my own local machine and used it, until we started using VS.Net 1.1. The only SourceSafe around was SourceSafe 6.0 which was connected to VS 6.0. I was not sure how SS 6.0 and VS.Net 2003 would play together and did not have time to experiment. (Later I found out they play together fine, but by that time I had already upgraded to SourceSafe 2005.)

Sterling chip Camden
Sterling chip Camden

I knew the guy who wrote it. He was just that way. He left a few months before I tried to port it.

StarNamer
StarNamer

From the description, i.e. uncommented code with labels all of a standard form (L####) using obscure facts about the instruction set, I'd say that your 'program' was actually the machine code output of a compiled program which had been saved (and perhaps subsequently modified) when the original source code had been lost. As such, I'm not surprised it was impossible to port to another architecture and indicates very poor source code maintenance rather than poor documentation and commenting. Many older compilers used to translate source into machine code and assemble that to produce an executable. If someone lost the original source, they could continue to make minor changes using the machine code and not have to admit they'd lost the source!

Sterling chip Camden
Sterling chip Camden

... in my book. Even working independently, I always use source control with versioning. Saved my butt more times than I can remember.

joeller
joeller

Ahh but we didn't have any VM software because the Navy wasn't willing to pay for it. In fact we didn't even have Source control except what each developer devised own his or her own.

Sterling chip Camden
Sterling chip Camden

Keeping around old versions is what VM software is for. Better yet, the good ones will allow you to branch and merge.

joeller
joeller

We didn't have any kind of change tracking software but there was a Change Request Process. That number, the date, the author, and the reason for the change had to be included. The customer then came up with the idea of additionally inserting a comment on the line or the block of lines of lines listing those first three items and keeping the old line or block of lines on the page commented out. While it can be considered useful to see the prior implementation as explanation for the change, this can lead to some very unreadable code in applications that require a lot of changes. They also required that when replacing pages in production a copy of the old pages be keep with a name change indicating date and author of the change. Many developers due to the large number of changes would instead copy the entire web application folder and replace it with a new version, (which would in fact undo the change tracking.)

Sterling chip Camden
Sterling chip Camden

I'll assume the voice of Dilbert's character Topper: I once inherited an assembly language program whose printout required an entire box of paper. It contained more than 3000 labels, all named l####, where the #'s were a sequential number. Total number of comment lines: 7. Name of program, author, date written, and a brief description. I was asked to port this program from Data General Nova assembler to Eclipse assembler. I had to give up. Not only was nothing documented, but the author also made use of idiosyncrasies of the Nova architecture to use instructions for multiple purposes (for instance, knowing that the upper byte of a particular instruction was a 1, and using that in place of a literal to save on memory usage. He also rewrote some instructions at runtime instead of using different sections of code. Regarding documenting changes: if you use any kind of change tracking software, I find it useful to include the tracker number in a comment. That keeps you from repeating yourself, doesn't clutter up the code, and keeps all the info in one place.

Tony Hopkinson
Tony Hopkinson

Why comments, nearly always useful. What comments rarely useful. Some places go a bit anal on them, my opinion is if you can say it in code instead of a comment, you should. Nothing worse than an explanatory comment that confuses, from that point on you might as well not have bothered, because no one will trust them anyway. The whole point of radical 'new' improvements like multiple character variable names, was so you could make your code more self explanatory. Comment is the mechanism, annotation is the objective.

Sterling chip Camden
Sterling chip Camden

Many's the time I've revisited a clever bit of code years later and wondered what I had been smoking at the time. Cleverness comes at a high price, unless it also instructs the next person who works on the code. And if the cost of cleverness is outweighed by its benefits, then I always comment what isn't obvious. One could argue that where comments are needed, code has failed.

Tony Hopkinson
Tony Hopkinson

Tony's way is the best way. Can't even say it's the best way for me, as I've confused myself on occasion sometime later. Any clue, no matter how trivial it might seem now, as to WTF you were thinking about then six months later, is worth it's weight in irridium. And sometimes thinking about it in those terms, may just Jiminy Cricket you over to an equally effective but more obvious implementation.

Sterling chip Camden
Sterling chip Camden

A very familiar sound these days. Now the snow is mostly melted, but we've had three power outages since the last snowfall -- mostly due to the wind knocking over trees that are losing their foothold in the moist soil. It's good to be able to compromise, as long as you don't end up agreeing to the impossible.

Jaqui
Jaqui

not downtown here they aren't. They are in the alleys.

Tony Hopkinson
Tony Hopkinson

breaks the minimum is occasionally achievable, of course minimum is a perspective.... There's nothing more soul destroying for a competent developer than a piece of code they dare not change. It's like the missing tooth your tongue keeps finding...

Sterling chip Camden
Sterling chip Camden

... to kludging -- shoehorning a change into a complex, poorly-designed system in a way that breaks nothing is nothing short of magic.

Tony Hopkinson
Tony Hopkinson

I do a lot of chenges to other peoples code, or stuff that has to integrate with it. The code base is well poor, but the levl of interdependancy, coupled with poor/nonexistent documentation, means I have to very pessimistic on estimates and risks. Hence I end up doing the minimum, and nothing gets better. Talking more code quality than product quality. I actually look forward to those occasions when the cost/risk of bodging finally outstrips that of doing it properly.

Editor's Picks