Think first, code later

http://24ways.org/2012/think-first-code-later/

by steverydz • 14 years ago

56 14 14 years ago

strictfp• 14 years ago

If your code ends up like that you probably missed having a sustainable rate, pair programming, code reviews, refactoring and writing testable code. So you missed a lot.

Silhouette• 14 years ago

Unfortunately, the reality is that any code base that is maintained and developed over an extended period will "decay", even if you don't do anything wrong.

This is a simple consequence of the fact that you usually don't know everything and can't create an idealised long-term plan up-front. Instead, you start with certain goals and try to implement a sensible system that meets those goals. As time goes by, your goals change or you add new ones, and you have to adapt that existing system to match.

Often, during the time since the initial development was planned out, you may have developed newer techniques for solving your problems, or you may have new tools available that weren't before, or you may have worked with some new people who have better ideas about something. In short, you may have a better way to do things than before. Now you have exactly three choices:

1. Stick to your existing design/ideas and don't use the better ways. (Pros: Maintains consistency and doesn't incur (re)training overheads. Cons: May cost more and/or get worse results for the new work, or may simply not be possible if you need a new approach to satisfy your new goals.)

2. Use the better ways, but only for new/future work. (Pro: Best cost and results for that new work taken in isolation. Cons: Might mean an entire new design co-existing with your previous one(s), with potential compatibility problems, integration costs, future maintenance overheads, etc, and might cost more to implement separately than it would have done if you'd known ahead of time and created a more general design to support both the old and new parts earlier.)

3. Switch everything to the better ways, a.k.a. The Big Rewrite. (Pros: Keeps your entire system using the best possible tools/ideas, and keeps the whole code base consistent and systematically designed across the board. Cons: Can be extremely expensive relative to incremental changes, you can easily lose little fixes/improvements that had been carefully worked into the original code base over time, and you may have to retrain some of your team before they can work with the new version.)

This is an exhaustive set of your options if you're going to do that new development but your team and the world have moved on since the original work. Every one of them has at least one serious downside, and unless you do a full rewrite across your entire code base every time you develop any improvement, those downsides always include some degree of inconsistency or stagnation.

zachallia• 14 years ago

Code. Think (on the toilet). Code.

glenjamin• 14 years ago

The main takeaway from this article for me is the part about questioning the use of jQuery.

jQuery is a great tool for doing things, but in the context of a rich javascript application, its tight coupling - and the even tighter coupling its plugin style encourages - lead to very hard to test code.

For example: jQuery.each is a fairly nice iterator function, and since you're going to use jQuery anyway - lets us that!

But then you want to try and test something in isolation, and you suddenly find that in order to iterate over an array, you need to load jQuery - which means you need a whole DOM environment!

fitzpasd• 14 years ago

For us younger programmers, 'Think first, code later' is without a doubt the best advice you can give someone going for their first interview. I still shudder thinking back to an interview when I threw myself straight into coding the solution to the given problem.

Stand back. Think. Draw/Design the solution. Code

ramayac• 14 years ago

Don't forget to document too :)

R_Edward3• 14 years ago

I am somewhat past the middle of a career as an analyst/programmer of various flavors. As I look back on the previous quarter-century, I find that the software I am most proud of is that in which the development effort was punctuated by frequent spells of pushing the chair back from the desk, getting up, and going for a walk about the facility. No destination in particular, just putting one foot in front of the other, probably with a glazed look on my face. Thinking about the project, the current hurdle, and various means of jumping it. Eventually I would surface from these cognitive dives, floors away from my workspace, with a decision on the optimal way to solve the problem. One of these projects is still running a global datacenter, largely unchanged, 20 years post-implementation.

Time to think is the most precious resource an analyst has.

locacorten• 14 years ago

Agreed. For me however I push myself to talk to others I respect about my work. This forces me to articulate what it is that I'm doing and why I'm doing it the way I am. I found this technique priceless.

R_Edward3• 14 years ago

Indeed--I find it works best when the person I'm talking to doesn't know anything about software, so that crucial points don't get hidden beneath a layer of shared abstract understanding.

georgemcbay• 14 years ago

Yes.

As a 39 year old programmer the most important thing I've learned is that my subconscious brain is way smarter than my conscious brain and the best way for me to solve a difficult problem is to think about it for a little bit and then not think about it for a while.

Later when I'm walking or in the shower or just waking up from sleep, a solution far better than any I came up with using focused thought will suddenly appear nearly fully formed in my head.

R_Edward3• 14 years ago

I've had that experience, and it's truly awesome. But I've never figured out how to make it happen on my timetable. :)

adrianhoward• 14 years ago

Time to think is the most precious resource an analyst has.

Which is another reason why the "normal" 50+ hour working week is so harmful to startups.

If all you're doing is coding and sleeping you're not leaving any time for thinking.

jhartmann• 14 years ago

While I'm not sure if I agree with every detail here, great article. For example I think the coding to design thought process has served me very well, you just have to have the right attitude about it and be willing to throw it away. My way to critically think is to put pen to paper, but other peoples brains might not work that way.

The whole process of doing minimal viable planning is profound, and a huge time saver when working with multiple people. If people have a rough idea of how the code will interface it helps them avoid lots of churn that doesn't really have any benefit.

johnpolacek• 14 years ago

Its funny. Having kids has forced me into doing this. When at home, I rarely have more than an hour of uninterrupted coding time. So when I have an idea, or get stuck, I'm forced to get away from it, letting my brain naturally chew away at it. I have less time to code, but my time spent is more efficient.

Think first, code later

Related Stories