Design-first vs. code-first

The Server Side has a hot thread on Design is not coding, coding is not design. As you might imagine, it has all the trappings of a Holy War. There are some interesting posts, though.

I think there's a misconception in the software world that there is some kind of silver bullet to making great software. Sometimes languages are held up as a silver bullet. Sometimes it's tools. In this case it seems to be methodology, specifically design-first vs. code-first type of methodology.

What do I think? Well, I think it takes a team of dedicated, talented people to make great software. It takes good ideas, good design, good project management, good code, and good customer support. Without dedication, talent, direction, and sound practices it doesn't seem to me that any of the things you must be "good" at is possible.

So, design-first vs. code-first? Yes. As long as it fits in the context of a good practice that allows your firm to make good software.

I would like to create a methodology called "Holistic Software Development". It's mission statement would be something like "get good, hard working people to focus their talent and energy on turning great ideas into great software that empowers customers through excellent practices". It would be a methodology framework that other methodologies could plug into - something like the Spring application framework. But, it would tie them together in a way that supported it's mission statement.

But, what do I know?

No comments: