Trying to design while in the act of writing code often produces poor results, whether the design is for a few lines of code or an entire system.
On the other hand, the keyboard is a fantastic place to write software.
It depends. Maybe on average it is true, but for very competent software engineers, the keyboard is amongst the best tools to perform design.
Of course, TheSourceCodeIsTheDesign. For those activities which precede coding (such as a PaperModel), a keyboard may or may not be the tool of choice.
The famous quote of EwDijkstra
applies yet again: a formula is worth a thousand pictures
It is no doubt in my mind that formulae (expressions in a formally defined language) define software design much better than diagrammatic UMLs or whatever. The only valid contention to be made is that traditionally (for Dijkstra) the best place to write formulae was on paper.
The situation changes by leaps and bounds, and I fully expect that in 2 decades even mathematicians will write their formulae entirely on computers. The bravest of them already do that. When it comes to software engineers, many of them do perform software design on the computer using a formal language. The philosophy and the approach is documented in books like OnLisp
. Furthermore people like KristenNygaard
the father of OO contended in his BetaLanguage
book that software design should be done within
the language and that it was his idea all along to do it so, and the same direction was expressed by BertrandMeyer
, and I am not 100% sure but I think it was also the philosophy of early SmallTalk
pioneers (anybody can confirm or invalidate this ?).
Apparently the ThreeAmigos
and the UML gang have entirely forgotten these extremely valuable insights.
A question for those who believe TheKeyboardIsTheWorstPlaceToDesign
: where is a better place to design? Is there a "best" place? -- AnonymousDonor
On a beach, lying in the sun, with pencil and notebook in the sand. Or walking to/from courses/work. Or in the shower (seriously; I usually memorize most hard problems and solve them in the shower).
If I'd read this page a couple years ago, I would've thought it nuts. But I'm starting to really hate the computer (which I guess is kind of a bad thing for a beginning software engineer). It makes me feel cramped and confined and gives me eyestrain. I found my productivity this summer jumped dramatically when I started taking a walk around the block mid-afternoon.
If there's nice weather out, I'll even take a notebook outside and actually write code
on pencil and paper for my volunteer projects. I can type it in to the computer later, and I find that it's much easier to concentrate on the hard problems if I don't have a computer screen in front of me. IsAnythingBetterThanPaper
? -- JonathanTang
In practice, there's almost always a delay between the time I first hear about a project/feature/requirement and the time I start coding. During that delay, I figure out a rough design while eating, showering, working out, walking, etc. That rough design is generally in place when I sit down at the keyboard.
(DATK) is roundly condemned by such luminaries as LeoBrodie
, and the years have taught me that DATK is a bad idea.
at the keyboard -- that rocks!
Note from the future.
Before these speech interfaces were conceived, the keyboard was the tool of choice for direct, and invariably individual control of the computer. This spawned the concept of the PersonalComputer
. Before the GlobalHumanMachineInterface?
Unfortunately, I misspeak badly, I mean I don't always say things good, I mean I am orally error prone. You know, I really, really, really miss the backspace key.
This page seems to be an example of a personal preference being touted as a universal truth. Unless someone can make a valid argument why the keyboard is at least a bad place to do design, then I would suggest that this page be dropped entirely.
One reason I feel that paper is a better place to design than the keyboard is that paper has a better UI than the computer, at the moment. With paper I can draw lines to connect things, I can draw pictures, I can see much more all at once. With a keyboard, I can only see about 60 lines at a time.
Perhaps we could change it to list the places which are bad places to design - the keyboard, underwater, on K2, on the Titanic. And good places - the dunny, a coffee table, in front of the computer (carefully avoiding the keyboard somehow), the train.
With WirelessNetwork s they are all one and the same. Even underwater (http://www.link-quest.com/html/oceans2000.pdf) or very high mountains (http://www.cellular-news.com/story/8727.shtml). Perhaps state is more important than place - for instance Design software before eating. That way you'll stick to the SimplestThingThatCouldPossiblyWork so you can go foraging sooner.
A cafeteria table is the best place to do AnticipatoryDesign?
. The screen is the best place to do ReactionaryDesign?
. If you want to be good you have to learn to work both.
Talking of cafeterias, design software before eating. That way you'll stick to the SimplestThingThatCouldPossiblyWork so you can go foraging sooner.
How about Pass Unit Tests, Then Eat, Then Refactor? One can complete a "design" in a very small period of time, without actually accomplishing anything. So a better goal would be to get something working quickly before the break, and then come back to it later to improve it without any time pressure? If there is insufficient time to get things working, then maybe Write Tests, Then Eat would be the ideal strategy.
[RefactorMe] Also, eating a large meal will cause more blood to be used for digestion and less for thinking. I've also heard that (generally speaking) we do math better in the morning. I've noticed personally that I program and design better in the morning, especially before everyone comes in!
It might be better to forage throughout the day so you never get the sleepy feeling after a big lunch. One should prepare suitable food beforehand; otherwise snack food will seem the most attractive option and gain in productivity from never being hungry or dopey will be offset by the loss caused by heart attacks.