Thanks to much of the boring work being done already in modern programming environments, that self expression is visible to end users instead of being exhausted trying to fit the designers "Oh, I've got 24 function keys" onto two lines of 80 characters in a meaningful way.

use echo <machine code goes here> > <executable name>

Creativity isn't something you learn, it is just there in the makings. You recognise what you have and build upon it. Creative people make the most of what they've got and go beyond. If it wasn't the imagination and the creativity of the pioneers in a given fields, human race would not have advanced much.

My point is, no, today's programmers are not more / less creative. It is very difficult to make that comparison.

Take a good old Apple 2 (64K Ram, 1Mhz CPU) , a disk drive (140K) and a Visicalc program. Start the machine (cold start). Type your first formula after ... 8 seconds. This has for sure required creative solutions.

I am not in nostalgy, but could the creativity be used to align today performance to similar standards ?

Creative possibly in the "look and feel" department but not as much so in the background process. I think a lot of bloat has appeared because today's programmers have access to a lot of resources (CPU speed, RAM, hard disk space) which just wasn't around 20 years ago (hell, even 5 years ago). Optimisation seems to be a thing of the past.

I would say that the kind of creativity in a computer programmer of the 80s and the kind of creativity in a programmer these days are put to use in different areas.

In the 80s you generally had 400K of RAM to play with (after the OS overheads, etc.), and a 4-8MHz CPU or so. 20MHz at the end of the decade, but I was using XTs and ATs in the mid-late 80s.

We did some amazing things in a few K of RAM, and frankly you had to. You had to think hard about how you could cut back on memory usage and clock cycles. My own opinion at the time was that removing the limitations removed the incentive for programmers to *think*.

After that, I would say that programmers tended to think very little about how their software will work, and spent more time thinking about how it would look.

Of course, it's all a matter of perspective. For the most part, the software created today works as well as software of its day ever did. These days it's all web-driven, with a slick UI - but even those come out of a box now. So where's the creativity now?

See, in the 'old days' people had to come up with fiendish algorithms to make their stuff run at all. After computers became more powerful with more available resources, programs started to look better (but remember Word 6 against Word 2? The UI was 'improved' but it was not a snappy application - it sort of lumbered into existence when you double-clicked on it, like the behemoth it was), and people concentrated more on appearance because they could.

But nowadays, where's the focus of this creativity? You get algorithms coming out of your ears in the frameworks of today. UIs are bought off-the-shelf, for native apps or websites.

So where to now? Show me where this 'creativity' is going? I don't see it myself.

(No Paris Hilton angle?)

I'm a twenty something or other and I think engineers in general HAVE to be creative. Whether it's creating a brand new build process or creating a file structure that will run on a system with hardly any disk space and will load fast, both of those require creativity of some sort.

You need foresight to design around roadblocks but creativity to elegantly handle the unexpected roadblocks or other phenomina (such as managing spiraling complexity of source code).

My point would be that it is is only the developers on the front line (of either performance or bleeding edge) that are being creative in the classical sense. Most others are just working within the framework provided or copying ideas off the web (although we all do this). However they may be being creative with UIs or requirements gathering or internal tools. There is a much larger field to be creative IN these days.

However I still think us young uns are fooling ourselves if we think we're more creative than our predocessors. Just read the documentation on the MS's Word file format! LOL!

From Wikipedia: "Creativity is a mental process involving the generation of new ideas or concepts, or new associations of the creative mind between existing ideas or concepts. An alternative conception of creativity is that it is simply the act of making something new."

I suspect most software development now falls into the second type.

But for the purpose required I think what is meant by "creativity in software development" must be clearly defined.

And should the "creative" item be (a) functional, (b) useable, (c) required and (d) commercial ?

I'm sure others could add other items to the list.

I'm slightly thinking of those "amazing" web sites that people design which are all graphics and movement but which are a total pain to navigate and can take a day to find what you were looking for (if you had the time!). Are these creative?

Just my ha'penny worth...

You have to take several things into account.

Firstly, there are definitely more developers today than 20 years ago.

Secondly, there are more tools opening the opportunity to be creative than there were 20 years ago. But how are you defining creativity? Just because an application has cool graphics doesn't mean it required more creativity than finding a way to build a 16 bit calculator using an 8 bit platform. I was using LOGO to make some really really cool stuff back in 1985. It might not have been a 3D FPS, but it looked amazing in its own way.

Its like asking "are artists more creative if they have acrylic + canvas rather than just chalk + cave?" Probably not, but the field in recent years has attracted more "creative" types.

I myself am an artist as well as a programmer. I started painting first, but I was instantly drawn to the art of coding when I first used LOGO at age 7.

It all depends what you mean by "creative". Nowadays there are masses of SDKs and APIs that do virtually all the heavy lifting, so developers can while away their days choosing between various sickening shades of colour and deciding how to lay out their Web pages so they look different from other people's. If you're a developer, that may seem creative.

But ordinary users would prefer applications that are simple, easy to use, and reliable. Sites that never give you 404s or SQL Server dumps, take days off because they're feeling poorly, or lead you round and round in ever-decreasing circles in the search for some simple function. Above all, sites that do have "feedback to Webmaster" links on every page, and that don't ask you to fill in lengthy forms with all sorts of personal information, then reject the input for some arbitrary reason and lose all your input. (Yes, DVLA Swansea, this means YOU).

Setting aside the times when dinasours roamed the earth, I'd say that proportionaly there is very little in it. Yes, we can all point to risen legions of point-and-drool cut-'n'-paste programmers with very little in the way of creativity, but there is an equally vast legion of highly talented programmers.

It's simpler to get "in to" programming, ask any bedroom webmaster with his LAMP stack, but by the same measure the amazing advances in all areas of comp sci have enabled new heights of creativity and productivity to be scaled.

Simple - developers now have more time to be creative - less time spent waiting on slow hardware to compile our code, less time spent doing boring but highly necessary grunt-work, more time to solve the real problems thrown our way, and to come up with creative, elegant solutions.

Personally I am constantly confronted by an inability to model data properly, and the number of reinvented wheels I see drives me nuts.

o-o databases - Codasyl/Hierachical databases - nothing new and quite often implemented poorly

XML databases - Codasyl/ ditto

What's a primary key?

What's a foreign key?

I am not very good at things like CSS, beyond a certain level, and the young guy on our team is very good at it, so it works.

I was trained to start from the data and then build the software on top of it. This is still a valid approach and none of the UML stuff has ever made me change my mind. Use cases have to be maintained if you want to use them past requirements capture - people are only human so they aren't. The database will never lie about what the intentions were when it was created.

Creative in the context of the young programmer you mention probably means being able to get some Ajax to produce pretty diagrams. I can do it, I've even coded some of that stuff raw in the old days before we had the JavaScript libraries we do now. I also use languages like Ruby to do my day to day work - but I was using Awk and Sed many years ago, and if you just want to write a script these now-neglected languages are still very useful.

I can also go right down to the 'C' if I have to - not that many of us left.

use a butterfly...

http://xkcd.com/378/

I don't think creativity is a question of what you create but rather how. Creating a 4k executable that displays 3D graphics and elaborate sound, that's art. That's creativity. Using a premade 3D engine with bells and whistles to make an immersing game is creative as well, though, and can also be art.

So the argument of "we were more creative because we had to make our own tools" is not quite right, in my opinion. While earlier programmers were more or less forced to spend some of their creativity making day-to-day tools, they did not waste it. Neither do programmers today using those tools to make new things. The next generation of coders will use what those before them made. Why reinvent the wheel?

Now I did not experience the way programmers had to work "back in the days", I started coding in 1995 using GFA-BASIC for the Atari ST and later QBASIC for the PC. Still, I do think I was creative back then. With today's tools, I can form that creativity into code way easier, that's true.

I can do without GUI Builders, WYSIWYG designers and all that stuff but I really, really need syntax highlighting for any coding. That's something that really feels natural and needed today. Consindering project tools... Hm, at least a network between all team members as a bare minimum. The more tools you can get, the better.

But they still don't actually produce software which actually works.

And given the wonderful checking tools they have these days, that is unforgivable.

I would like to see a games developer keep my attention for 70+ hours with 1.44MB

Ian bird did that with Deuteros.....

Then there was FA/18 hornet 1.44MB disk only what 7 or so missions awsome games

and so on and so forth.....

Dont get me wrong the games of today are impressive, but they do lack something......

Are programmers more creative today? Applied to the general population of programmers, I would say definitely NO! There are certainly many intelligent and creative SW developers about today but there's one thing that's very different today compared to the beginnings of the SW industry and that's passion (or lack thereof).

In the old days, SW was an area that attracted mostly students who were passionate about SW but that's no longer true today. SW in developing countries, where more and more SW is being outsourced, is no more than a job for most of its practitioners. They don't do it because they love it but because it pays well. That shows in the quality of the SW they produce. If you want to produce good code you've got to love what you're doing, they clearly don't.

So, from a statistical viewpoint, there are more talentless morons developing code today than yesteryear and so the average creativity is much lower.

First, on the definition of creativity, I think it's worth noting that developers twenty years ago were just deciding how a mouse should interact with an application. Should there be one, two, or three buttons, and how do they operate? They developed creative solutions like the left button performs the default action, while the right button brings up a floating menu for less common operations. That particular solution was so good that the creative developers of today are still using it without any modification. Compare that creativity to any Web 2.0 interface you've seen.

On the question of what software tools would be most important for a new project, I would say it's a good version control system for the code. A unit-test framework helps too, but not as much.

I've got more admiration for the creativeness of games programmers from 20 years ago. They had such little memory and in particular storage space to work with and invented clever ways to work within those confines. I vaguely remember the first game to contineously load data from the floppy disk so there was a short loading time, no pausing during the game or short levels - some modern games would do well to benefit from that. And the first games to have human speech which was a technical marvel way back in the early 80's.

Modern programmers don't have the same struggles and as this articles says they've got tons of tools and libraries to help them work and get around problems that they can (thankfully) be oblivious to. Could you imagine writing a top class app or game from scratch without relying on any existing tools or libs?

Are just as arrogant as they were 20 years ago ;0)

They know everything (apparently), I can remember when I thought I knew everything - I must have forgotten shitloads!

God bless the little darlings

What you describe is that when technology is primitive, the mechanics of cut and paste require more specialist knowledge. As platforms are today easier to use, the total creativity is much greater, though the individual contribution may have dropped.

The ideal project takes existing data, shows it in a useful new form, and costs nothing. Wikis come pretty close to this ideal, for instance.

*For proof, see John Livingston Lowes, "The Road to Xanadu: A Study in the Ways of the

Imagination", Boston: Houghton Mifflin Co., 1927 or a short summary like http://www.xanadu.com.au/mail/xanadu/msg00192.html.

For Java J2EE - toolset:

Eclipse - Perfectly good IDE, would be nice if it had deeper integration with ANT

Checkstyle - boring and intrusive, needs base rules tweaking, but consistent code style is good

ANT - local builds, deployment

Subversion - Version management

Hudson - Build tool, nice reporting, easy to install. Configure to build every couple of hours, stopping at least one hour before people start to go home. Last thing check-ins punishable by death.

JUnit - doesn't help with UI testing, should be compulsory for business layer & below

Clover - Code coverage tool, integrate this with build and hold people to a decent level of coverage

Jira, Fogbugz - or equivalent bug/job tracking ideally should integrate with version management

Umlet - very basic UML/diagramming tool, works with Eclipse but doesn't get in the way

Firebug - vital tool for javascript debugging

Wireshark - for figuring out what's going on at the lowest level

Work environment -

Decent dual screen setup, proper desk space

Test target box(es) networked so deploy and test can be performed on system matching the live platform spec

Decent source of tea/coffee - no vending machines!

Large set of whiteboards

Separate readily available meeting room for discussions

Kitchen (minimum kettle, toaster, microwave, fridge, dual dishwashers),

Chillout room

Shower

Things to avoid:

Power point,

Progressing to new code before fixing poor unit, code coverage and code style scores.

'Personal projects' within the overall codebase - code ownership is good, building empires is not

General observation. Whilst it flatters developers to make them feel individual, consistency of environment shows consideration for their fellow developers and a willingness to work as a team. Editors, PCs and toolsets that are 'their favourite' or customised to hell are a good sign of a diva in the making, or a set of code that no-one else can work on.

Developers should be given an environment where they can finish components off to a satisfactory status before moving on to the next piece. Coding frenzies, late-night working, skipping tests and missing documentation should never be necessary if the timescale is properly managed. It's the manager's job to buffer their team from external pressures and let them get on with the job.

Difficult question. I'd say that the possibilities of creative expressions are greater now, given the tools that allow that expression. However, it took creativity to imagine and create those tools as well.

On the whole, I'd have to say that no, there is no more creativity today than before. What there is a lot more of is recycling of old ideas and branding it "creative". What was creative was when those ideas were first proposed - in the 1980s, 1970s and even 1960s or 50s. There isn't much creative about copying an old idea whose time has come, much that the patent offices would like people to think so. So much of what passes for "creativity" is just recycling.

In 20 years we'll be able to look back and determine exactly who was being "creative" and who was being "derivative". Until then, we'll just have to put up with the self-promoting assholes who copy others then claim they "created" something.

I am on the fence. I've been programming professionally since 1997 and as a hobby since 1983. I'm currently using Visual Studio 2008 when my last language was Delphi. Whenever I have to revert to Delphi to fix some legacy issue, I feel like throwing things around it seems so clunky. I couldn't imagine trying to code something in Borland Turbo Pascal or C++.

What the modern languages allow me to do is be creative on the fly. Back in the day, programmers had to keep a hard vision in their head of what they wanted to do without being distracted by the nuances of now old programming tools. (An old adage is you don't have to know PowerBuilder to be an effective PowerBuilder programmer, you just have to know how to NOT crash the development environment.) But in reality, there wasn't anything better so the frustration of reverting to something less programmer friendly wasn't there.

Having said that, the other end, most of my creative ideas don't come while sitting in front of the computer coding. They come while I'm in the shower, about to fall asleep, watching the boob tube, or something like that. I get the flash in the pan, then I work it out on paper or a whiteboard or a napkin in a bar. Once I have a good idea as to what I'm wanting the app to do, I code it out. Even with archaic development tools, the idea is still in my head, the tool is just a limitation on how easy it is to produce.

As far as pure creativity, I always think of the "killer app" scenario. The last completely fresh killer app I can think of would be Napster. Facebook and MySpace are really just a modern version of the old BBSes I would mod almost 15 years ago. That being said, if you gauge creativity by the "killer app," then modern coders fall short.

In summary, I would say yes and no. Modern development tools allow programmers who are more easily distracted by the actual building of the application to be less distracted which may or may not allow them to be more creative. The old way of circumventing this was to do your creative thinking offline, working it out and hammer it out.

My no answer would be based on the lack of killer apps written in this millennium.

So every company I've been at recently has been using a "flat" source control tool. I mean flat in that it's branching capabilities are so painful to use and unreliable that it's not worth the effort. Instead #defines and such are used to chunk out code and people have to manually "version" the code on their machines to keep track of new changes that shouldn't be going out into the world yet.

Anyway, point being, branching source control and allowing developers to create brances as needed to allow all code be in the repository and backed up and easily identified and rolled back is probably one of the biggest advantages today. This easy transition from today to yesterday to 3 weeks ago allows the rampant "playing" with new ideas/designs and still allow you to not loose something you did a month ago "accidentally"

More people can dabble, which is your point. This is like more people painting pictures at the local arts program. The pictures are crap but they have fun and they have something of their own to hang on the wall.

You also ignored the huge number of "business process" "applications" which aren't really any more creative than writing a memo.

Making something creative that changes lots of peoples' lives is hard work and hasn't changed significantly over the past 25 years, whether you're programming a major, scalable web application (e.g. facebook, google) or an embedded app (e.g. ipod). Those still take creative work once the prototype is done.

Application developers – definitely more creative! 20 yrs ago, I only had a few function keys or 4 letter menu codes in which to navigate, so my taxonomy had to be bang on (Believe me, knowing the right way to describe something is just as important as what is actually does). Presentation of data in a logical format and grouping on 24 x 80 screens became an art in itself.

Creativity.

There's an old art-school joke.

Q: What do you get with an art class and 50 pounds of clay?

A: 50 pounds of ashtrays.

(This was funnier when folks knew what an ashtray was.)

Creativity is only important if the creator has something to express. Most automation processes are not expressions, they are solutions. Occasionally, a solution will occur that is brilliant, exciting, novel -- in short, creative.

Is it creative to put a new look on a component? Or is a creative to make a brand new presentation foundation? I would suggest the latter is creative. The former is merely exploitive.

Given the hundreds of APIs and productivity tools (Eclipse, VS, Hibernate, Infragistics, Ideablade, Googasms, and the like), I think most of the self-congratulatory programmer's hype comes from that exploitation of a tool that already had a capacity for the property. (You mean this can be ANY color?)

The work I see coming from the ANSI committees can verge on creativity (if it doesn't devolve into politics). IEEE can be the source of so much creativity, you can almost forget they have pocket protectors and still know how to find the log on a slide rule.

The other area of creativity I've witnessed is in interfaces. Those hidden bits of arranged marriage between one system and another, one data source and another, throughout an enterprise can sometimes look like genius. These are data creations -- translations that never occurred before. I'm not sure they are creative in the way this article poses.

There is a huge impediment to creativity in the industry. Francis Fish (above) implied the roots of much of the industry's failure. The whippersnappers don't learn the history of their art, nor the current state of it before they start slamming bits and blocks together to solve their first problems. Anything creative, then, usually happens by accident (which has its place, but is better if you are prepared for it).

It is most likely, then, that the creators in our industry are the writers of compilers, designers of protocols, O/S developers, and especially the hardware designers.

You want to find a real creative genius? Look for a Ph.D EE working in hardware-based encryption.

You want to find a pretender who gets to look good based on the long hours the Ph.D EE put in behind new chip capability specifications? Just look at the programmer next to you.

Someone else mentioned it but there is a difference between creativity and productivity. Today's developers certainly have productivity enhancement tools that weren't even feasible as late as the mid-90's however; today's developers aren't building anything fundamentally new. It's sort of like LEGO - someone designed all the wonderfully versatile blocks that let "the user" build what they want: today's developers are "the user" of LEGO - about as far removed from the creation process as possible.

Secondly, you don't really want creativity in a developer. You want them to build a project. Getting developers thinking creatively is like asking engineers to think creativity - a very bad idea. Applications don't need creativity they need to meet their end use goals: nothing else, nothing fancy, nothing "scalable". If you asked a bridge engineer to design you a bridge you'd want to be assured that it would work (i.e. not fall down) for a long time. If you asked him to be creative, on top meeting all the other specs (cost, life cycle, design/build time) you'd end up with nothing more than a shitload of weird drawings and flowery buzzword concepts; in the end you'd never have a bridge.

What development needs is a truly standardized way of doing things (at a higher level) and a greater understanding of business as a whole. So much of the tripe you hear developers spew is technical garbage that's obsolete almost as soon as they say it. By the time they get done whining about how to do something "right" the situation has changed (technology made their way wrong, or the business need has changed) - resulting is a product (if ever delivered) of secondary quality and questionable function.

The best tool a developer could possibly have is business sense. Not only would they get on with their colleagues/bosses better, it makes it a lot easier to get what you want (bigger monitors, faster machines, hot secretaries, etc...)

The worst tools a developer could have is more techno-wonder tools that only provide another avenue for failure.

Clue time, script kiddies!

There is something called "design." That means NOT CODING AT ALL!!

Believe it or not, design has been touted for decades now. How many of you have been writing code over ten years? Twenty? Thirty? I started in 1980. I will tell you this: modern programming isn't worth dog feces.

How many of you are taught design, real design, in school? Any of you? How many of you pick it up after you leave? Any of you? Here's programming in a sentence: figure out what you want it to do, figure out how it's going to do it, key it in, see if it works, and jump between any of the preceeding as necessary.

But get this about the "figure out how it's going to do it" bit: the concept is called design! This is writing software, not writing a novel, a play, or a dramatic opera. It is all about getting a black box of bootlegging binary bits to all go in the direction you want. And how do you know you've got a good idea about that? Design! Learn a methodology or two or three, apply pencil to paper, and off you go.

Metalanguages (ML) like Haskell and F# are the rage. Do you know what those looke like? They look like someone took Jackson Structured Programming and made a language out of it. What was JSP developed for? COBOL! Yes, that old thing. What was applied to COBOL to get stuff done is applied to languages. Why? Because most "programmers" are too lazy to learn how to design. But maybe they can be made to learn a new language.

Languages are "cool" but real design is not. I work with a newly minted programmer fresh from college, and I found out that I can't discuss state machines with him. Not at all. He immediately goes frothing at the mouth that state machines are antithetical to his personal ideology. But if the language encapsulates a design concept, he's all for it.

There are plenty of real horror stories about software that has literally caused death. One that always stuck in my mind was the radiology machine that gave over twice the set radiation dosage when it was placed in a certain position. How much real design went into that software? How much real testing went into that machine? And how many of you would consider yourselves capable of writing critical software where someone's life could be jeapordized by a bug in your code?

Any of you?

Learn some design and get with writing solid code.

...but they sure have a lot more to deal with:

"What we used to call systems integration is just system administration nowadays"

http://codeasaurusrex.com/wordpress/?p=8

The wider palette of paradigms certainly provides greater scope for creativity than the "FORTRAN, Assembler or COBOL" trinity of bygone days. (Whether the average programmer takes full advantage of it is another question.)

Define "creative" before asking the question.

"Creative" as in terms of turning out original ideas - probably not. It's the question of the killer app - and we've not seen one of those for a while. But you could argue that it's a field that has evolved very quickly - not so much scope for truly original stuff anymore.

"Creative" in the bodging sense? Not so sure. Back in ye olden dayes, had to write funny code to squeeze into memory limits and/or get decent performance, but these days do more data-transfer bodging.

"Creative" as in the sense of producing something "artistic"? This is a very difficult one. Ca we consider code to be a prose poem? etc. etc. I've seen very elegant code, well commented to the point where you could argue that there is a real narrative. I've also seen specs that are beautifully done.

I'm agnostic as far as the question goes. I think one of the real problems with judging this question is that the result of the development process is often not a thing in itself. It is merely a platform, a substrate, a medium for others to work with. For example, do you think that the development of something like Reason is comparable in terms of creativity to what end users do with it? Arguably, developers work to a specification. And this allows for very little creativity.

And I wonder about "creative" solutions to concrete problems. I've sat in "problem solving" workshops where people mention Edward De Bono. Lateral thinking and "outside the box" - my arse. I do formal methodologies - but it is interesting that the ignorant seem to think that I'm being "creative".

Mine's the one that says something along the lines of "there is no philosophy of science, science IS, philosophy merely pretends to be."

Yeah you. You are spot on in your statements. That's the kind of thinking the IT world needs more of.

The only bad part about this entire story is that it's says it has to do with "Agile Development" - which is a huge techie buzzword and everyone is looking to cash in. Agile Development is not about making development better, it's about selling more tools (which funnily enough aren't developed by "Agile" teams in some of the more better known applications).

20 years ago programmers had to write VERY efficient code that worked. Today, they just need to write code that does the job and its not awfully slow, they can add features as long as the overall program is still usable.

@yeah, right: creative vs. derivative... fair point.

@Brian Miller: design versus programming... spot on.

Previous comments posted = stroll down memory lane... almost a tear or two.

@OzBob: 24x80 screen... yeah; CP/M on Z80 2Mhz CPU, 64k RAM, s-100 bus, 8" floppy...

or creating replica Chrysler Electronic Lean Burn system using RCA1802 CPU, plus pressure and temperature transducers... even design the circuit board... derivative for sure, but had to put heaps of creativity in to get it working [Waikato Tech Institute, NZ: 1980]

All contributors to this thread have valid comments. Young prog's throw away line; he/she blissfully unaware of the effort required 20 years ago; same goes for anyone without an appreciation of the past, in that technology is built on layers of history... which are buried under each successive layer (made of PC-XTs, retired 3745 FEP's, etc).

IMHO, creativity in this context is more to do figuring a novel way around an obstacle, not how many tools there are to do it... best tool is your brain.

Analogy time: car along road; tree fallen over in the middle; way is blocked, car stops. (alternative route adds 500miles to journey)

*00s programmer; 2008*

Consults GPS, where am I? Ah, here. Tries mobile.. damn no signal. Try SMS.. ah, that works.

Gets reply in 10 mins "emergency services there in 15mins" (yeah ok, that would be nice!)

.. plays game on PSP, listens to music CD/MP3 in car

Truck arrives 20 mins later, 15 people, 4 chainsaws, 1 crane

Prog offers to help, but elf'safety officer declines as could get sued... half hour, job done

*80's programmer ; 1988*

Out of car, looks at tree, scratches head... hmmm, looks closer at tree.. flat down or leaning on main branches? leaning... weight mostly at lower trunk... flexy branches at top, less weight

Can move it, or leave it - time/effort/risk... decision = go for it

Takes tow rope out of car, ties onto top of trunk and to the front chassis mount (why front, why not tow ball? coz more weight at front where the engine is; also tie to chassis as could rip the bumper off... {proper analysis of infrastructure} )

Gently reverse taking strain, move tree out enough to get past; leave rags on sticks either side of tree as warning to others... job done in 10 minutes

Drive towards destination, stop nearest phonebox to alert police of said tree; police advise tree removal the next day

Note: 2008 vs. 1988, different sets of tools, and levels of delegation available. 1988 no GPS, no mobiles, no CDs, no MP3.... just simple and effective application of brainpower with limited tools available... where DIY was a requirement not a casual alternative

@James - couldn't agree more.

Creativity can't be planned or estimated, its a thinking process with no defind outcomes. Maybe thats connected with today's projects hardly ever delivering useful software on time. Perhaps what we need is development teams with less creativity and more skill.

The tools of the developer start with some standard knowledge. If I see any of these on a co-worker's bookshelf, I know I am working with a professional. Language, platform, problem domain, and business environments change. Fundamentals do not. And some of these fountains of knowledge have nothing (and everything) to do with applications, development, or computers. They have to do with life, the universe, and everything.

- The Art of Computer Programming, Donald Knuth, Vols I, II, and III, Addison-Wesley Professional

- Numerical Recipes (In C, or 3rd Edition, or whatever) The Art of Scientific Computing, Press, Flannery, Teukolski, Vetterling, Cambridge University Press

- Managerial Accounting, Garrison, Noreen, Brewer, McGraw-Hill

- Statistical Process Control: The Deming Paradigm and Beyond, Second Edition (Kindle Edition), Thompson, Koronacki, Chapman & Hall/CRC

- Autobiography of Thomas Jefferson, Jefferson, Dover Publications

- Walt Disney The American Dreamer, Tumbusch, Tomart Publications

- Elements of Style, Strunk & White, Allyn and Bacon

- Metamagical Themas: Questing For The Essence Of Mind And Pattern, Hofstadter, Basic Books

- Computer Organization and Design: The Hardware/Software Interface, Patterson, Hennessy, Morgan Kaufmann

- The Feynman Lectures on Physics including Feynman's Tips on Physics: The Definitive and Extended Edition, Feynman, Leighton, Addison-Wesley

- The Fuzzy Systems Handbook, Cox, AP Professional

If I were starting a project, I'd make sure the following tools were in place:

- Requirements Management

- Testing Plan

- Source Control

- Defect Tracking

- Change Tracking

without these, it's hard to know what you are build, and track how well it is being built. Tools are just a part of the equation, you should also have

- Clear Customer Requirements (not implementation notes, or "just make it like xxxxx")

There are also specific jobs that should be filled at the start

- Configuration Manager

- Build Manager - if you got more than one developer, someone needs to make sure builds are done in an orderly fassion

These aren't glamor jobs, but without them, things get pretty messy pretty quick.

- John (SW Eng at heart, Config Mgr by need)

PS: Creativity is writing code to fit into 64K RAM and 128K of ROM on an embedded processor with a total address space of 64K that allows only 32K of ROM and 16K of RAM available at one time.

IMHO the proportion of true currently active creative developers has dropped.

IMHO the number of true currently active creative developers has increased slightly.

In the past 10 years I have seen the proportion of lower level developers increasing rapidly. That is the developers who are not 100% hand coding fluent and must rely on RAD GUI tools (usually Microsoft) to develop with.