The Case for Slow Programming

Goes generally against Agile, but a fantastic read. I agree that the development process should pump the breaks a bit more to ensure the code is fitting the goal of the project, that it’s simple and that it’s foundations are strong.

The push for funding and books like “Do more faster” does spur the Agile movement but this isn’t a bad thing. Agile is still valuable, taking thorough breaks to fully test and check code are an absolute necessity then since the code likely has flaws. Doing this also allows all designers to stay “in-the-loop” about the logic so the next changes can be built with a firm understanding of the current working model.

Nature -> Brain -> Technology

My dad used to say, “Slow down, son. You’ll get the job done faster.”

I’ve worked in many high-tech startup companies in the San Francisco Bay area. I am now 52, and I program slowly and thoughtfully. I’m kind of like a designer who writes code; this may become apparent as you read on 🙂

Programming slowly was a problem for me when I recently worked on a project with some young coders who believe in making really fast, small iterative changes to the code. At the job, we were encouraged to work in the same codebase, as if it were a big cauldron of soup, and if we all just kept stirring it continuously and vigorously, a fully-formed thing of wonder would emerge.

It didn’t.

Many of these coders believed in thefallacy that all engineers are fungible, and that no one should be responsible for any particular…

View original post 887 more words


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s