The trend in software development is to have faster "turn-around" times to deliver features and fixes. Overall, I consider this to be A Good Thing- as practices that improve efficiency in software development are needed for this profession to remain credible. That being said- in every implementation there is an element of design involved. This design work is the most nebulous part of Software Engineering because very little is actually produced. As one colleague put it, "we talk a lot about working...". This tends to drive "results oriented" members of the team (like the accountants that have to figure out how to pay for our competitive- and entirely justified- salaries) absolutely nuts, because (at best) they get some Visio Drawings and MS Word documents, but no executing code.

However, this is an absolutely critical phase of the development cycle- even for adding a relatively simple feature. The reason for this goes back to a basic principle of mine: Software is the digital manifestation of a mental construct. Since software is manifesting a mental construct, that mental construct MUST be well defined and designed. Inherent flaws in that construct will manifest as inherent flaws in the software that support staff will be dealing with for the rest of the software life cycle. Therefore, the more thought put into defining and designing the mental construct before ANY code is written, the better the overall solution is going to be. It is much easier to change the design while the mental construct is still in a flowchart, ERD, and/or spreadsheet rather than compiled code implemented in the client's production environment.

This is when software development can approach the level of "artistry" as opposed to being mere "tradecraft". Designing the object models, data entity relationships, are the software engineer's equivalent of the composition of a photograph or painting. ERD's, procedure flow diagrams, and UI wireframes, and Object Model flowcharts are the developer's "sketchbook".

However, all of this design work takes concentrated thought and time. I can tell you from personal (and very bitter) experience that this investment of time in just "thinking" DOES pay off in the long run with solutions that are easier and cheaper to implement, support, and modify. This comes from having mental constructs that are well designed- meaning that they meet the identified requirements, are flexible enough to anticipate probable future requirements, and logically sound in objects, data definitions, and procedure flow. Those characteristics of good design then head off most of the common issues that occur in software development- speeding up the actual implementation, and significantly lowering the amount of effort needed for support on the "back end" of the life cycle.

So, if you hand a software developer a new project- then later see him with his feet propped up on his desk staring into space while sipping a highly caffeinated beverage- chances are that he is NOT "wasting time doing nothing". Instead, it is likely he is taking the first steps in building the mental constructs needed to provide the best solution to the business problem you handed him that morning.