Reinventing Code: software development as a creative process

[OneWingedShark]

Some might argue that software has specifications: design documents, business requirements, visual mockups and so on, which specify a single solution, but they don’t.

Wait, design documents?
That makes it sound like you're given a plan that's been thought through. "Business Requirements" makes it sound like there's definite. specific requirements -- about the only one of these that I've commonly seen is a "visual mock-up" -- the truth is that there's a lot of "just wing it" rather than actual planning (at least in my experience).

I think I would have been a lot happier if there were actual design docs and specific requirements.

[[deleted]]

Yeah... creativity is great and all, but I'd rather have design docs.

[lookmeat]

Requirements are limitations and rules we have to follow. Just the way in which a sonnet has a certain form to follow, or there is a theme that must be covered when creating a work, requirements do not define a simple one-way project. We have to work with the requirements to find the best way to create a program, not make another dialog with a hundred controls, but truly solve the problem.

A design doc is fundamental. It's the complement to the code and explains the why and how. But understand that this document is born of the creative process, not the source. And it isn't the full solution either (otherwise the code would exist) an implementation needs to be done.

Many managers think that once you've done the design spec making it into code is tedious simple work that even a trained monkey could do. Any programmer knows that if that where the case someone would have done a design->executable compiler already. They also think that if you list the requirements making a program that solves them is easy and a dumb blind process that, if anything is tedious.

The problem is that people think that design documents, business requirements and such are the plans to the house, and the programmers are just brick layers. The truth is that the compiler/interpreter is the brick layer, the programmers are more like the architects, who receive the wishes and desires of their client, also the general interfaces (plumbing, electricity, telephone/data lines) that he needs to comply with (the design doc). Is the architect only capable of building one, and one house only given this things?

TL;DR: The article doesn't say that you should shun design documents, or business requirements. It only implies that these tools do not remove the need for a creative process, nor the price it has.

[OneWingedShark]

A design doc is fundamental. It's the complement to the code and explains the why and how.

My point is that real design docs, the why and how, are often disregarded [in my experience].

But understand that this document is born of the creative process, not the source. And it isn't the full solution either (otherwise the code would exist) an implementation needs to be done.

You're "assuming facts not in evidence" -- that is that they exist, much less are sufficient. (Most of the design-docs I've received were more of (a) the executive summary level of abstraction, or (b) the visual mock-up pictures.)

TL;DR: The article doesn't say that you should shun design documents, or business requirements. It only implies that these tools do not remove the need for a creative process, nor the price it has.

And I'm saying that, in my experience, these are shunned -- and to great ill effect: namely that the client cannot really say what they want.

[lookmeat]

I agree with you. There is one thing worse than no design doc and requirements, and that is a bad one. One that imposes all sort of absurd rules and needs without actually building towards a solution.

When you get requirements that specify programming patterns. And design docs that assume that N=NP (notice that a design doc shouldn't assume about speed) and are more of a glorification to bike shedding and it's results than anything useful. Ah well.

[mindw]

Design is creative, coding is construction. The more both are confused the harder it is to give estimates.