Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Slow Programming

ventrellathing.wordpress.com

Post reply on HN
Print view View original

171–180 of 346 posts

Re: The Case for Slow Programming

#171

Post by calinet6 »

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…

The best and most concise way I've found to explain this is a systems focus.

We aim to focus on systems, because it is the most efficient way to work. By using good methods, designing complex systems well, and spending adequate time designing, we achieve a net speed increase, productivity increase, cost decrease, and additional positive benefits such as programmer morale and overall quality.

In my mind, quality is the genesis of everything, but you do have to word that really well so that the overlords comprehend the consequences correctly.

Re: The Case for Slow Programming

#172

Post by anonfunction »

pzxc wrote: post #10

I recently disregarded the competence of a coworker (who is in a programmer position) because I took a class with them and saw that they could not type. They were hunting and pecking. (This guy is 50 years old so has had plenty of time to learn) Is that wrong? Does being bad at typing force you to be more thoughtful and actually make you a better programmer? Or does it just mean it takes you longer? My thinking is th…

Sure, if they are hunting for the correct keys that is a bad sign. However I don't equate super fast typing with actual speed of progress. Very rarely am I coding as fast as I can type. In fact, that never happens.

Re: The Case for Slow Programming

#173

Post by anonfunction »

pzxc wrote: post #10

I recently disregarded the competence of a coworker (who is in a programmer position) because I took a class with them and saw that they could not type. They were hunting and pecking. (This guy is 50 years old so has had plenty of time to learn) Is that wrong? Does being bad at typing force you to be more thoughtful and actually make you a better programmer? Or does it just mean it takes you longer? My thinking is th…

Sure, if they are hunting for the correct keys that is a bad sign. However I don't equate super fast typing with actual speed of progress. Very rarely am I coding as fast as I can type. In fact, that never happens.

Re: The Case for Slow Programming

#174

Post by fsloth »

forgottenpass wrote: post #130
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…

With specific skill sets, you can build architecturally sound systems at no extra cost. Except the extra labor costs of someone with that skillset.

I would like to respond that the maintenance costs and thus TCO will be lower for the better designed system - however I have no idea how to formulate this into a tenable economic argument since I have absolutely no data to back this up.

Re: The Case for Slow Programming

#175

Post by rumcajz »

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…

Programmers are craftsmen. They need vocational schools. Academia is not up to the job.

Re: The Case for Slow Programming

#176

Post by fsloth »

m0nastic wrote: post #54

I hesitate to recommend my process to other people, because I don't think I'm a very good programmer. But for the past year or so, I find that I program best by actually writing out my program in a notebook (in my case a quad-ruled lab notebook). I don't even start typing until I have it laid out pretty much in it's entirety on paper. This sounds ridiculous (and I can imagine it's not practical for all types of progr…

Paper rules.

I had to add a new feature to a decades old user facing codebase with had to interact with all of the existing system. The implementation of the core of the new feature took only a few hundreds of lines of code since it was just a bunch of graph operations basically. Interfacing with the rest of the system was hell.

I began by just investigating the requirements and designing on paper. I realized on my paper designs quickly that a few graph operations would be sufficient. Understanding how it fit with the rest of the system was only achievable to me by documenting for myself on paper how the bits and pieces worked I had to touch.

Took half a year to get the sucker ready.

Worked just like it was supposed to and my colleague praised how easy the codebase was to extend later on.

Paper and carefull design. It just rules.

Re: The Case for Slow Programming

#177

Post by shizzy0 »

pauldprice wrote: post #153

Glad he doesn't touch type? What a lame excuse for not mastering the tools of his trade! That's like a carpenter saying he's glad he never properly learned to use a hammer. There is a time and place for a steady pace and thorough design process, but not in the early stages of a startup. If you can't keep up with your user's feedback and market demands then you'll lose to a scrappy team that can, no matter how beautif…

Yeah, who needs entering code to be a challenging "mini-game" instead of an automatic, non-thinking skill of typing?

Re: The Case for Slow Programming

#178

Post by shizzy0 »

mattxxx wrote: post #102

I'm all for programming slowly, but how many pieces of code are built slowly, and, in the end, turn out to be built wrong or cumbersomely? It seems like, if you write slowly, you gotta have legitimate deliverables and tests at every step.

Excuse me, are you asking for data? for evidence? We're here to assert our opinions, speculate on what's best, and cite an anecdote—sadly.

Re: The Case for Slow Programming

#179

Post by wmt »

rumcajz wrote: post #175
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…

Programmers are craftsmen. They need vocational schools. Academia is not up to the job.

That's actually the problem! Many current engineering disciples were before handled by craftsmen until scientific principles were applied to it, making it engineering.

There have been very few scientific studies about the basics of building software, like how much unit tests really affects the bug density, and those few studies go often unnoticed when teaching future software engineers.

It would require a major effort to first study the existing emergent software craftsmanship practices to find common patterns and to scientifically evaluate their effectiveness, and the results would have to be taught in the hypothetical future curriculum where future software engineers would be made. Then we might have software engineering instead of just software craftsmanship.

It's almost a bit amazing that software "engineers" who can be very obsessive about getting the data or A/B-testing will craft software based on methods they have no data about.

Re: The Case for Slow Programming

#180

Post by jsilence »

rapind wrote: post #168
lectrick wrote: post #125

Earlier quoted context omitted.

Relevant: http://knote.com/2014/11/10/why-germans-work-fewer-hours-but...

I now love german culture. It's like finding my soulmate.

Please note that another german culture is to be overly pedantic in following rules, no matter if their initial intention applies or whether we just set them five minutes ago. Rules are followed because.

This culture makes administrative processes bulky and tedious and tiring.

It often fuels my Ungeduld, because I want to get st done zügig.

Post reply on HN