Comments On Principle Seven

Comments on Principle 7 of SevenPrinciplesOfSoftwareDevelopment, "Think!"

: ...and see ThinkingAndCoding.

Once again, I must disagree. Many of the problems I am called on to fix have come from too many two hours meetings spent piling speculation on speculation. My alternative- Do! (then Reflect) -- KentBeck

Finding a good balance between Thinking and Doing is a central part of human nature. I don't advocate thinking a problem to death, but I certainly am tired of programmers giving only cursory thought to a problem before Doing. Many times, their solutions are not correct or violate the system architecture, and there isn't always time to go back and Reflect (and fix). I think Booch said that this can lead to "software rot." -- DavidHooker

How do you think if you don't know how to validate your thinking? If you have a new technology, a new domain, or if you're just new to the design process, you can agonize for days because you simply don't know how to decide. Is newness always doomed to failure? -- BrianSchuth

Yes! Precisely! So get on with it. Then reflect and change your behavior based on your insights. -- KentBeck

Hmm. Personally, I prefer to think while I do. Partly about what I'm doing, partly about what I shall do, partly about what I have done (some of which may need changed). Very conveniently, parallelism is feasible: forget the chicken/egg problem of whether to think first or do first; just get on with both. -- EdwardWelbourne.

Very little of what we do is truly new technology. If you have no domain expertise, do some research. How have other people solved this problem before? Isn't that the purpose of Patterns? If all you do is sit down and start hacking out code you'll just end up re-inventing wheels. -- EricMiller

A programmer who has read about trading is a programmer who has read about trading, not a trader. I don't mind reinventing wheels. The best way to learn not to reinvent wheels is to sit with someone who is in the process of reinventing a wheel for the fifth time. Patterns can help somewhat with this process, but the problems I have aren't addressed with patterns yet. --KentBeck

I saw a project where no thinking was performed. The project had a 'no time to think we need to get this done' attitude. Everyone was 'doing' so much they didn't talk to one another. There was three separate string classes. Rather than do some thinking and abstract some logic, code was cut-n-pasted all over. It was a disaster. The project ended when the company went bankrupt, after five years of 'doing'. Anyway, I have also seen projects spend so much time thinking that nothing ever got done. Balance, like DavidHooker stated, is key. -- EricMiller

Order is as important as balance. I wait until I have something to think about before I think. Coding without thinking doesn't work. Thinking without coding doesn't work, either. The question is which to do first. I derive considerable advantages to designing in the presence of tests and code. I also derive considerable advantages from testing, coding, and refactoring in the presence of another developer. --KentBeck

OK. I can agree with that. Thinking is not about design as much as it is about being aware of the process in general. Recognizing when a design is ready to code and when code needs more design. Being aware enough to notice that a development effort is thrashing or out of control. -- EricMiller

Seeing this I realized how long it was since I had gotten to agreement with anyone on wiki. Perhaps I'm just a disagreeable bastard. Anyway, one last gush and then one of our VolunteerHousekeepers can summarize-

For me, a design is ready to code as soon as I can see how to get my tests running. Code needs more design either on the downslope of getting the tests to run, when I can see similarity, or when I can imagine a way for the current code to run that will make getting the next test to run simpler. --KentBeck

Aah. I like that. However, I have to admit that I never, ever, sit down and start hacking until I have something on a piece of paper. For me it's just an exercise that tells myself, "Yes, you did think about this. Yes, you did come to some conclusion. Yes, you are ready to begin work." Ready to begin is not the same as ready to complete, though. Many times I have tried to explain to somebody else (no pair programming around here) what this particular method does in changing this object's state. Only when I try to explain it to somebody else do I see the holes in my own design. Stuff I left out or didn't even think about in the first place. At that point I leave the keyboard and go back to the pencil and paper. It's iterative. -- MartySchrader

I would like to suggest "There is no substitute for understanding"; from which it follows that you should think -- yes -- and do -- certainly -- but for some people doing is how they gain understanding, and for others thinking (before and after) is how they gain understanding. I think I agree more with "Think!" than "Do and Reflect" unless the doing is interpreted as part of the thinking process. The very real danger is that there will be no time allocated to reflection -- either through lack of inclination or high-level-pressure -- and so this laudable aim can fail to garner the essential understanding (and worse, not bother to communicate this to those who follow). -- StevePowell

I would like to suggest that there is no right answer to this. Don't do all your thinking followed by all your doing and don't do all your doing followed by all your thinking. Isn't this just another form of the XP principle that talks of many small guiding inputs to navigate us to our goal? You need to think-do-think-do-think-do or do-think-do-think-do-think (to me reflection is just thinking in a different time frame so do-reflect == do-think). So I second the ideas that talk of parallelism and iterating (but I hope I added something too). If the size of the iteration is small enough (such that it approaches a parallel activity) order becomes less important. Whichever comes first to you and gets you moving towards a solution then go for it - but don't exclude the other activity otherwise your doomed. -- JohnHarding

KentBeck would you consider expanding on I don't mind reinventing wheels. (or point me to somewhere I can better understand your meaning behind what appears at first to be a very contrary statement)? Thanks. -- JohnHarding

If you've been programming for a while, unless it's a new domain, i can't imagine a need to just do. It should be straight forwards to figure out what you need to do. Any questions can be resolved with a rapid prototype. This is an approach that works for many many people. I think it's personality based, not necessarily related to how it should be done. The only thing i dislike is someone saying it can only be done one way. When i take a trip i figure out the route first, i don't get in the car and take it one road at a time (although sometimes i do). -- ExperiencedProgrammer?

I don't think it's true that "any questions can be resolved with a rapid prototype." You certainly don't test parachutes and airbags that way, eh? The need for reflection and internalizing the learning phase is really repressed with XP, or so it seems. How does this phase of development manifest itself in XP? -- MS

Every child has played with a prototype of a parachute. A pillow is a prototype for an airbag. The way in which an XP project will manifest that learning has taken place is, I suspect, very much the way any enterprise will : whatever you have been doing, you do it better the next time around.

There doesn't need to be a separate "phase" given over to this aspect of learning, though XP does have several tactics which contribute : pairing to propagate experience, the writing of tests to encode technical knowledge...

Something makes me feel that the think versus do dichotomy (a FalseDichotomy at that) serves a creeping laziness, and without that laziness the choice vanishes. Laziness may be the wrong word for it. The problems are hard, and you're a little tired. Doing without thinking is a lazy response to that. The hope is that what's done is right, but without hard thought it probably isn't. The thoughtless doer just repeats known solutions, but doesn't look for the misfit to the current problem. Thinking and not doing is a different lazy response, but a more subtle one. Without the doing component, there is no closure to feedback, and so no mechanism to corral thinking into the hard regions of the problem.

As I sit here thinking and doing (writing), I am wondering to what extent these activities actually differ from each other. We are blessed (or cursed) with human intelligence. That intelligence is based in a model of neuronal connectivity that allows us to simulate problems in our heads. This is short-circuited doing, in a nutshell (my cranium!). I'm getting very fast feedback, but it's from the model in my head, not from you. That has its advantages and disadvantages, but think about other techniques we employ for verifying things in isolation. This is a form of unit testing. Dig it. -- WaldenMathews

Laziness is what it's all about. Well.. laziness and the drive to get lots done.

Computers let you be lazy by doing something once where a more energetic person would do something over and over.

But, creeping lazyness, as described above, is more like being overwhelmed. If you're programming for money, you get paid for delivering the needed work on time, or some such like that. And, if you can understand what's really going on -- what you really need to do -- you can be lazy, getting your work done with time to spare. If you mess up though -- if you have to try too hard to get there -- you get snowed under with all the things you have to do.

If that's where you're at, what you gotta do is arrange things in priority order and satisfy the top priorities first. If that means you can't be lazy, or if that means you don't have time to think about what you're doing, so be it. It'll cost you, big time, but priorities are what keep you sane.

Re: Always ask "what if ", and prepare for all possible answers by creating systems that solve the general problem, not just the specific one. This could very possibly lead to the reuse of an entire system.

I am generally against pure YagNi, but this is extreme to the other end. Striving for the Ultimate Generic Thing is a dead end. Not to mention PrematureGeneralization. GenericLimits