The Case for Slow Programming • Hacker News Board

Re: The Case for Slow Programming

#201

Post by cxseven » Tue, Dec 02, 2014, 8:35 AM UTC

John Draper, AKA Cap'n Crunch, made a great case for it: "It was a perfect coding environment, coding in jail. [...] Those long nights without the computer really got my smarts in top gear, as I really focused in getting the code perfect and bug free. Not having a computer some of the time, got me to thinking more about writing good code, and less time debugging. During this time, I wrote a really cool FORTH debugger that allowed single stepping through FORTH code (Totally unheard of in those days).

I also write a De-compiler that would take the compiled FORTH code and re-generate source code. This was invaluable in tracing down some gnarly compiler problems in FORTH. You see, I was not only writing a word processor, but I was also developing the language on the fly as well. Modifying the compiler, interpreter, and I even write a DOS (In forth) to manage the easyWriter text files, because EasyWriter didn't need DOS. So I implemented one, using a FAT (File allocation table) and all that other Gnarly Disk Operating system low level code. I found out that FORTH allowed me total flexibility. If the language didn't have a feature, I implemented it. Simple as that.

The day finally came when I was to be released from jail, and Matt had already rented a fully furnished apartment in West Berkeley for me, and met me at the jail when I was released. That evening, we met at the IHOP on University Ave to sign the contract YAY!! and the incorporation papers YAY! Now we can call ourselves Cap'n Software Inc. We rented office space on Telegraph avenue a block from the UC Berkeley campus and called it our "Corporate Headquarters".

Soon we got our first royalty check of $3500, and I gave Matt $1000 of it and put him on a salary. Michelle, Matt's roommate and holistic friend was hired on as our Secretary, and handled all of our bookkeeping. WOW!! I get out of jail and in 24 hours, am president of my very own software company. SUPER COOL!!" http://www.webcrunchers.com/crunch/Play/ibmstory/

Re: The Case for Slow Programming

#202

Post by dlitz » Tue, Dec 02, 2014, 8:37 AM UTC

Floegipoky wrote: post #194

wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

Unfortunately, the process of building houses can't be compared to building software. Houses don't get bolted sideways onto scyscrapers 5 years after they're built, or suddenly need to accommodate multiple order of magnitude more people than they were originally built to hold. These are regular occurrences in the software world. You are right that most people that come out of university are woefully unprepared to des…

> The tough sell is trying to show management that the alternative creates technical debt that will strangle the project if it isn't addressed

If you're worried about that, then the problem is that you have someone managing a software project who doesn't know how to manage software projects. That's not a failure of the methodology; it's a failure organizational design.

Re: The Case for Slow Programming

#203

Post by lyudmil » Tue, Dec 02, 2014, 8:38 AM UTC

In general I think there is a case to be made for "slow" programming, but this article falls short for me. I happen to think that software development is a knowable discipline, that we're in the process of figuring out how to build the kinds of systems we need and struggling with a new kind of engineering where there are no physical constraints.

Therefore, I think we have a lot of exploring to do in order to come up with practices that reliably lead to better software and certainly the speed of the development process and the number of iterations is an important thing to experiment with.

However, the post is too wishy-washy to teach anything meaningful. What does "dot my i's and cross my t's" mean in the context of software development? What does "something like implementation-ready code" mean and why is it useful? How do I, as a person separate from the OP, get from where I am today as a developer to the super effective zen-master you're telling me I could be? I'd love to read that post, because the one I just read makes it seem like I should wait to get older and take up gardening.

Re: The Case for Slow Programming

#204

Post by aragot » Tue, Dec 02, 2014, 8:41 AM UTC

Argorak wrote: post #45

wellpast wrote: post #22

I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. Our goal is architectural soundness. I believe the biggest fallacy of our industry is we think the only way to get these is to go "slow". Not true. What we're really saying…

> I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. German has a very nice word for that: "zügig". It means "speedy" as well, but goes a bit towards "stable", "steady" and "friction-free". It's the good kind of fast, which…

"Zug" means "train", "-ig" makes it an adverb like "train-ly". Can a German speaker confirm please?

In English, I'd say a train has a fast & steady speed, therefore I propose the translation "steady".

Re: The Case for Slow Programming

#205

Post by dschiptsov » Tue, Dec 02, 2014, 8:41 AM UTC

> You can’t wish away Design Process.

Furious activity is no substitute for understanding.

Before you start to writing the code, YOU HAVE SPEND A LOT OF TIME STUDYING YOUR PROBLEM. (Brian Harvey, CS61A)

If you can’t write it down in English, you can’t code it.

Programs must be written for people to read, and only incidentally for machines to execute. Immortal classic.)

The sooner you start to code, the longer the program will take.

Details count. (Devil is in the details).

Get your data structures correct first, and the rest of the program will write itself. (Data structures suggest algorithms).

Premature optimization it the root of all evil.

There is nothing new, of course. In "old times", even if "old programmers" didn't have such marvels like Java or Javascript, being mostly scientists, they have figured out "how their minds work" and in what kind of processes they are mere parts.

An one sentence summary could go like this - "Programming is an engineering discipline, Coding is a translation skill". To write down quickly one has to spent a life-time thinking and doing.

Re: The Case for Slow Programming

#206

Post by tempodox » Tue, Dec 02, 2014, 8:53 AM UTC

aragot wrote: post #204

Argorak wrote: post #45

Earlier quoted context omitted.

> I largely agree w/ the argument here, but "slow" is going to be self-defeating nomenclature, and is also inaccurate. Business doesn't want slow. So if we're pitching slow, we're setting ourselves up to lose and the speed-hackers are going to win. German has a very nice word for that: "zügig". It means "speedy" as well, but goes a bit towards "stable", "steady" and "friction-free". It's the good kind of fast, which…

"Zug" means "train", "-ig" makes it an adverb like "train-ly". Can a German speaker confirm please? In English, I'd say a train has a fast & steady speed, therefore I propose the translation "steady".

Confirmed. I think, “steady” is a good rendering.

Re: The Case for Slow Programming

#207

Post by alxndr » Tue, Dec 02, 2014, 8:57 AM UTC

georgemcbay wrote: post #114

owtM wrote: post #72

Earlier quoted context omitted.

> I type about 105 wpm using four fingers > I also don't look at the keyboard > I just know where the keys are from muscle memory You are touch typing though. You may have an unconventional style, but that is irrelevant.

I guess it is touch typing if you define touch typing as any kind of typing without looking, but it isn't what most people think of touch typing, I don't have any sort of "rest" or "home" position.

I never really considered a "home" position, but I think my fingers do tend to end up around roughly the same keys between thoughts: [L-shift]SDF / KL;'

Re: The Case for Slow Programming

#208

Post by ploxiln » Tue, Dec 02, 2014, 9:13 AM UTC

sysk wrote: post #188

woah wrote: post #141

Earlier quoted context omitted.

I found go to be quite cumbersome in comparison to npm. Magic folders in the filesystem and such. With node you never have to do more than npm install and everything is ready.

npm (and the CommonJS module system) is the #1 reason I use Node.js. I don't care if Javascript is ugly, npm totally makes up for it. I don't get why most module systems implicitly import symbols in the scope (Python, Ruby) or worse, those that pollute the global scope (PHP). Brew (Ruby) is not that bad but Python's package ecosystem is a complete mess (distutils, setuptools, pip, etc.). Cabal (Haskell) is pretty goo…

npm is easily the worst. Python is a lot better. I hold the C library model as the golden standard, so we're not going to see eye-to-eye.

The worst part of npm is the sub-dependencies. Having enabled them, they proliferate endlessly. Each time I improve the efficiency of deploying a strictly controlled tree of modules, the front-end devs manage to double the number in use. 200, 350, 650, over 1000... oh and these improvements come from realizing that npm-shrinkwrap isn't 100% reliable, and ending up with scripts comparing npm-ls output and doing full wipe and replace with a tarball for even the slightest change to the dependency tree.

If some serious bug is discovered in one of these things, there's no way the 20 copies of it at various levels of this tree of 1000 modules are going to get patched. No one really has a handle on what's in these hundreds of megs of various versions of modules. This is the true fast code movement - serious problems can't be fixed in there, they'll just be ignored and replaced with other bugs in the twice-yearly full rewrite. Don't get me wrong, our frontend devs are among the best I've seen, but the pressures and environment they're in make them focus on churning out the latest fad in web design and skimping on engineering quality everywhere possible.

Python doesn't do implicit import of symbols into a scope if you don't use "from blah import (star)". Don't use the (star).

Managing, and using, a list of python modules, each at a particular version, is way simpler, more reliable, and more efficient (than npm style). Pip can reliably list installed module state (freeze) and install from source tarballs or git tag checkout.

You need to fully control and understand the versions of all libraries installed and used on a system in order to have a fully reproducible deployment state, and be able to reliably roll back to a previous state. Given that, the Python or C model is much easier to work with.

Re: The Case for Slow Programming

#209

Post by ikurei » Tue, Dec 02, 2014, 9:23 AM UTC

sdrothrock wrote: post #144

barking wrote: post #100

Earlier quoted context omitted.

Zügig is just so..Germanic! It's exactly how I imagine the stereotype of German efficiency. In the anglo-saxon world we pride ourselves on how many hours we work. In Germany they work fewer hours and produce more and of better quality. At least that's my impression.

Latin has it in festina lente -- "Make haste slowly."

I've always loved the spanish saying "vísteme despacio que tengo prisa", "dress me slowly, I am in a hurry".

Re: The Case for Slow Programming

#210

Post by duncanawoods » Tue, Dec 02, 2014, 9:45 AM UTC

idibidiart wrote: post #32

Has anyone read this book and for those who have is there a correspondence here? http://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/...

I don't think it has a direct correspondence in terms as you might be implying i.e. the fast in this context is mostly still the slow Type II reflective thinking DK refers to. The "fast" coders are making small iterative changes but that doesn't mean the thinking is automatic, just localised and frequent.

The deeper analytical and design oriented thinking where someone takes extended time to identify goals, prototype and review different implementations is an important variation of Type II but not really addressed in TFAS. There might be plenty of Type I micro-decisions involved in that process too.

I'm pretty interested in how cognitive biases do rear their heads in design problems. I'm scared silly by framing effects where given options A and B, an individual chooses A but adding a third option C and now they would choose B. There are so many decisions that crop up during design/development that are vulnerable to those issues.