On “Make It Work Make It Right Make It Fast”

Ward’s wiki: “Make It Work Make It Right Make It Fast”

If you never make it Right – you will fail.

If you never make it Work – you never ship. You have failed.

The tension between these frames the art of software development.

There are no golden hammers to navigate these waters. Don’t let anyone fool you.

On Quality, Speed, Practice: Software Development links for October 18th, 2009

Microsoft Research: Janie Chang: Exploding Software-Engineering Myths:

…there is one point that gives this software-engineering myth buster a great deal of satisfaction.

“I feel that we’ve closed the loop,” Nagappan says. “It started with Conway’s Law, which Brooks cited in The Mythical Man-Month; now, we can show that, yes, the design of the organization building the software system is as crucial as the system itself.”

Bruce Eckel: 5-2-03 Strong Typing vs. Strong Testing

Random Thoughts: TDD is not test-first. TDD is specify-first and test-last.

97 Things Every Programmer Should Know: Uncle Bob: Speed Kills:

If you want to be a professional, if you want to be a craftsman, then you must not rush. You must keep your code clean. So clean it barely needs comments.

Coding Horror: The Xanadu Dream:

Consider the reality of what’s actually possible, what people can understand, and what us all too human programmers can practically implement. It might not be the Xanadu you dreamed of — heck, it might even suck — but it’ll at least have a fighting chance of existing in reality rather than fantasy.

Dare Obasanjo: Duct Tape Programmers and the Culture of Complexity in Software Projects:

The urge the reduce the complexity of the tools used to solve software problems is one that every software developer should share. However even more important is reducing the complexity of the actual solutions that are delivered to your customers at the end of the day. End users can’t tell if you used complicated C++ techniques like template metaprogramming and mixins to build the application. They can tell when your application fails to solve their actual problems in a straightforward way or is so late to ship due to project delays that they lose interest in waiting for you to solve their problems.

“Programming is an exercise in overcoming how wrong you’ve been in the past.”

Kickingbear: “Blog Archive » Don’t Be A Dick: Compiled Flash and You.”:

Programming is an exercise in overcoming how wrong you’ve been in the past. At first you’ll overcome the syntax errors, then you’ll overcome the structural errors, and then you’ll come to align your code with the standards of a greater community and you’ll feel safe and like you’ve made it. You haven’t – you’re still wrong because you’re always wrong. You are playing a game you cannot win. And let’s face it – if it was a game you could win you’d not be playing at all.

via Arpit’s Web Quotes tumblr

Old classic essay on software artistry/craftmanship: “Hackers and Painters”, by Paul Graham

Paul Graham: Hackers and Painters:

When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work– that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

I’ve never liked the term “computer science.” The main reason I don’t like it is that there’s no such thing.

…For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you’re writing them, just as writers and painters and architects do.

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

Make sure to read the whole thing.

I’ve disagreed with Graham on a number of things over the years. In particular his assertion that “good hackers prefer Python to Java” (note that ‘hacker’ in this context refers to a software artisan, not the caricature you see on TV), but as I get older… well I’m appreciating Python more and more and my realize just how right he probably is.

Programming (software artisan/craftsman?) Links for October 7th, 2009 – Don’t be an engineer – be a craftsman, be an artisan

Andrew Hunt and David Thomas: The Art in Computer Programming

Design By Gravity: Don’t be a Coder, Engineer, or Developer: be a Software Artisan!

Linux Journal: Everything Your Professor Failed to Tell You About Functional Programming

Peter Seibel: Unit testing in Coders at Work

Programming Links for October 4th, 2009

Coworker and friend Kevin Fitzpatrick’s “The Masterless Apprenticeship” new series on learning and craftmanship. Absolutely fantastic.

rallydev: Jean Tabaka: Escalation is Killing Agile – Can We Please Stop It?

plope.com: You’re the Smartest Guy In The Room.. but please, try to restrain yourself.

org-babel: executable source code blocks in org-mode – I need to try this – it sounds amazing.

Pros and cons for NoSQL

Pros:

a tornado of razorblades: SQL Databases Don’t Scale (Hacker News thread)

Cons:

Code Monkeyism: The dark side of NoSQL (Hacker News thread)

Related:

Archives of the Caml mailing list: Message from Brian Hurt

Chris Williams , Co-Curator of NoSQL East, NoSQL: A Modest Proposal

Carsonified: Should you go Beyond Relational Databases?