I'm an incredibly slow programmer (in the hobby projects I do for the love of it, that is). My ratio of thinking to typing must be around 10,000 : 1. Just to give you an indication of how slow I am: there's this one nagging project on which I've been working more or less continuously since... 2001.
Thus, programming advice of the DTSTTCPW variety (i.e. 99% of programming advice) always makes me a bit uneasy. Instead of thinking - shouldn't I just be crankin' out code, putting it online, and blogging about it on LJ?
But a couple of days ago I made an observation: almost all programming advice applies to applications, but what I'm mostly working on are systems. Since then, I'm sleeping better.
As Dr. Theodor Holm Nelson says, you can't get to the moon by piling up chairs. You may be able to learn something about an application by cranking out a quick and dirty prototype. But for systems, prototyping seems futile. Either your ideas work, or they don't, and a quick gedankenexperiment will usually be enough to find out.
Of course, I don't want to denounce experimentation as worthless. You have to know whether your ideas will be useful and work on really existing computers. But if your system is so removed from reality or complex that you're unsure about that, you're probably doing it wrong.
Take Unix pipes. There's an early memo about the need for pipes from 1964. And in 1972, pipes appeared in Unix. Do you think they spent 8 years DTSTTCPWing? I don't think so. I think that in these 8 years they spent a lot of quality time thinking about the issue, and when they had the right idea, they just knew it was right, and went ahead and implemented it.
So, to all systems programmers out there: most programming advice isn't for you. Relax, and take the time to find the right ideas.
Subscribe to:
Post Comments (Atom)
8 comments:
I'm also incredibly slow at typing in my programs. I too believe that it's worth it to get something closer to correct the first time rather than knock together a piece of a crap in a day.
Of course overdesign sits at the opposite end of the spectrum.
Do you think they spent 8 years DTSTTCPWing? I don't think so. I think that in these 8 years they spent a lot of quality time thinking about the issue, and when they had the right idea, they just knew it was right, and went ahead and implemented it.
UNIX has gone through all kinds of prototypes. Do you have any evidence for this claim that pipes sprang forth perfect and fully formed?
I don't see why "systems programming" is exempt for DTSTTCPW or prototyping. There are many dead ends, blind alleys, turnbacks, and Damascene conversions. Look at LKML for a window on this process.
8 yrs thinking without building at least one regretted prototype seems quite a stretch.
I think it's all "experimentation". The idea is to do something that will give you information with minimum cost.
So prototype code is an experiment. But so is a thought experiment. Also, a mathematical model. And even in developing a model, doesn't one experiment? DTSTTCPW can also be applied here, or to designing an algebra, or even a thought experiment. Is not the abstraction of mathematics - throwing out the clutter of irrelevant details - seeking the simplest thing that could possibly work?
A code prototype is a useful experiment for proving to others (and perhaps yourself) that it really does in fact work; for performance information; and for testing usability. It's also useful for seeing if people want it.
A minimum viable product (such as a website driven by hand - or even just an advertisement) is an experiment. One can also do usability experiments without code, by drawing it by hand; on separate cards and "running" it manually with users, or with a mockup tool like balsamiq.
A little story: when Armstrong was asked to design a telephone switchboard, he began by writing an algebra. It's a very low cost way for getting information about the problem domain and solutions that will work (if you have the necessary training and talent). Then, he wrote the first version of Erlang on top of Prolog. Both are ways of maximizing information for minimum investment.
I enjoyed the article very much, as it's good to be reminded of the value of a thought experiment.
"8 yrs thinking without building at least one regretted prototype seems quite a stretch."
http://www.bell-labs.com/history/unix/streams.html
It was, very roughly, indeed many years thinking, but finally an implementation and its refinement overnight.
That's also my experience with making changes to fundamental parts of systems, too.
As another example, Ritchie's design and implementation of streams for UNIX: (http://cseweb.ucsd.edu/classes/fa01/cse221/papers/ritchie-stream-io-belllabs84.pdf)see in particular the Evaluation section.
Well if one cannot evaluate our ideas without implementing them, one cannot for certain know what one is doing. Design is the most important phase of software developing, and a good design will always reduce debugging.
I agree about the design phase; I would never recommend skimping on the thinking. I always emphasise it in what I do.
Just not sure that 1) systems programming is "different" and 2) we can regard the streams examples ("build one") as definitive on the topic.
What about the endless second guessing of LKML???
Having read "Ritchie's design and implementation of streams for UNIX" I wonder if its lament over a few K of ram and the "inordinate amounts of storage" required for 1000 streams has turned negligible in the past 25+ years.
One can see 9P in this paper so I guess we already know the pitfalls :)
"Perfect is the enemy of done."
"In theory, theory and practice are the same. In practice, they're not."
This argument has engineering vs. academia (aka physics vs. mathematics) written all over it.
Post a Comment