The Case for Slow Programming • Hacker News Board

Re: The Case for Slow Programming

#321

Post by raintrees » Tue, Dec 02, 2014, 11:00 PM UTC

Karawebnetwork wrote: post #251

donatj wrote: post #97

I was once a "fast" developer, like thousands of lines a day. I could knock things out at an amazing pace but they always had problems and were rarely testable. That actually worked out OK where I was where we basically built things and ideally never touched them again. Now, 8 years later I write maybe 50-100 lines a day. I can see all the vectors of things that would go wrong and take the time to mitigate them. I wo…

Hotshot here. Oh, how I wish I could slow down. But how could I? My task must be done in time for the sprint. Everything I do must be logged into the right ticket, I need to time everything I do. The enemy is time, and I must defeat it. I wish I could output better quality code. Right now, I'm working on a project that was finished at 90% and I need to finish it. The code is horrible, but I have no time to fix it. So…

This conversation reminds me of an electronic relay assembly line I once observed over a period of time. The workers hand-soldered relays, their numbers were being measured/judged, so many cold welds were shipped.

QA sent them to soldering classes, where temperatures and flowing of solder were discussed/practiced. They came back with nicely soldered joints, and production numbers dropped to the floor.

Management came back in, exhorting higher numbers, so out came the cold welds again to make the numbers.

Re: The Case for Slow Programming

#322

Post by einhverfr » Tue, Dec 02, 2014, 11:20 PM UTC

discreteevent wrote: post #90

Retric wrote: post #51

Earlier quoted context omitted.

The problem is clean code is only a net gain when it sticks around. So, some teams are toxic to clean code. Let's refactor to use library X, no wait, libarary Y. There is a conflict with foo unless you use bar version 0.37c. Or the classic: "Works on my machine."

I used to think it had to stick around for some time. In practice you start paying for bad code after about a month and you pay back many times over. If a bunch of people are throwing poor code in, the payback becomes exponential before you know it.

Most of my work at the moment is done for a client which had exactly this problem, and it nearly destroyed their business. I came in about two years into the cleanup and things were still a mess. With a lot of work all around (and some pushing by me to focus on code contracts more), things have continued to steadily improve.

But the problem you mention is real and it can sink businesses.

Re: The Case for Slow Programming

#323

Post by placeybordeaux » Tue, Dec 02, 2014, 11:34 PM UTC

lectrick wrote: post #128

hasenj wrote: post #35

Earlier quoted context omitted.

I think we can learn from some other (not-so-obviously-related) disciplines. The game of go[0] has a ranking system where players progress from 30kyu (complete beginner) to 1kyu, then 1dan to 9dan (very strong). [0]: http://en.wikipedia.org/wiki/Go_ranks_and_ratings It's mostly statistical and based around comparing your skill level to other players. While a 7kyu level is not necessarily that well defined, and might…

It is the MOST trivial thing to measure performance in a Go game. It is the LEAST trivial thing to measure the "code quality"/"unit of time" metric in a programmer. For example, you might bang out an implementation that looks fine, but 1 guy will say "that will become unmaintainable in 1 year" or "that will be a problem if we ever switch databases" or whatever and sure enough, a year later, the team has to do that...…

>It is the MOST trivial thing to measure performance in a Go game.

Actually in terms of very old games Go is one of the harder ones to measure performance of during the game. In terms of measuring performance in any 1v1 game however it is easy.

Small difference.

Re: The Case for Slow Programming

#324

Post by einhverfr » Tue, Dec 02, 2014, 11:36 PM UTC

lmm wrote: post #226

Spearchucker wrote: post #103

This guy speaks to my soul . A couple years ago I worked on a project that tried to put a 40+ page printed form online. The form is complex. The form has a lot of intricate guidance and notes, and sections that must or must not be completed based on previous sections or fields. I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an adm…

> I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an admin change guidance on the fly, without touching HTML. Fields could be re-sequenced, data types changed. Business rules could be linked to fields dynamically, and applied to single fields or entire form sections. Data was saved to a SQL Server (already in wide use in the estate…

First, I sympathize with your reaction against building in functionality that is not required. This typically causes a lot of problems. However, for a library, that is less of an issue because you aren't maintaining it. It sounds to me like the guy used what was essentially a library he had previously developed to do this and that's a step towards having the flexibility in the right place.

> Why would your way have been different? If you are using the database to store logic in, it's still logic and still needs the same level of testing as it does in code. And you don't get existing tools like VCS, release systems, staging environments to help you with that.

My largest open source project does a lot with database stored procedures. We use all the tools you mention above, and we have written some of our own tooling to make that easier. So I don't think there is any reason why those tools don't work. So you have to spend a little time on tooling? That gets paid off many times over.

> I know we're just comparing anecdotes, but everywhere I've worked the business effectiveness has been directly proportional to the extent to which they actually followed the agile principles.

There are many things that agile gets right. As a reaction against the waterfall engineering model, the emphasis on integrating design into coding is a welcome advancement. There are many other things as well.

But agile development, because of short release cycles, tends to de-emphasize design and code contracts because it comes from the assumption of changing requirements, and here it gets a lot of things wrong. You can't do agile development if you don't have a stable platform to develop on because otherwise the ground is always being pulled out from under your feet. That platform needs to be well designed, and I am not sure you can do that iteratively without a fair bit of up-front thought. This doesn't mean a waterfall (except in the area of UX). Rather it means getting the right amount of design done at each level and having the right person do it.

Re: The Case for Slow Programming

#325

Post by einhverfr » Tue, Dec 02, 2014, 11:41 PM UTC

bitwize wrote: post #285

Here are my Reddit comments on this story: I've always programmed thus: * Try to assimilate a mental model of the bit I'm working on, and as much of that bit's dependencies as is practical, into my head. This may involve fiddling with the code and seeing how it breaks when I do certain things to it, or hammering at it inside a REPL or similar. The bit that I'm concerned about could be a single method, but is usually…

> - Development no longer relies on developers' internal mental models of the code. Developers now code against a model which is incarnate in the test suite -- itself a deliverable, documentable artifact.

And yet I have run into too many people who valued using the test suites for documentation.

IMO test suites should test that the software implements the documentation. Nothing more and nothing less.

Re: The Case for Slow Programming

#326

Post by _dps » Wed, Dec 03, 2014, 5:54 AM UTC

err4nt wrote: post #294

Spearchucker wrote: post #103

This guy speaks to my soul . A couple years ago I worked on a project that tried to put a 40+ page printed form online. The form is complex. The form has a lot of intricate guidance and notes, and sections that must or must not be completed based on previous sections or fields. I threw together a form builder by re-purposing old code from a side project that took me two years to polish. My proof of concept let an adm…

I come to coding from a Graphic Design background and I wish I had computer science under my belt as I test the waters of programming, but what I'm learning reading HN is that many programmers could benefit from the thinking they taught us in design school. What's the difference between an 'artist' and a 'designer'? One is employed! When you are designing something (even with code) your measure of success is how well…

> subtle text-shadows and gradients to enhance legibility (scientific reason)

Honest question: can you provide citations for this claim? I have been trying to produce a compendium of all the empirically-supported claims about visual design affecting usability. I have yet to find citable claims for these cases, and would greatly appreciate a leg up in the effort :)

Re: The Case for Slow Programming

#327

Post by beat » Wed, Dec 03, 2014, 6:43 AM UTC

jschwartzi wrote: post #165

beat wrote: post #65

Earlier quoted context omitted.

Paper is my favorite programming tool. The beauty of paper is that it's easy to find out when you're wrong, when you're pursuing the wrong path, without going deeply in and getting distracted by the small-scale details of the code. This gets right back to the design thing.

To put it another way, it's far less time-consuming to edit a Word document than it is to update an entire production system.

No, I need to get away from the computer completely. Word docs (or any other computer typing) is still bound by the computer structure and the computer distractions.

With paper, I can draw graphs of relationships, write tables, add notes to things I drew earlier, etc. It's far more expressive, and far faster, than any computer tool I've tried.

Re: The Case for Slow Programming

#328

Post by glurgh » Wed, Dec 03, 2014, 7:50 AM UTC

dang wrote: post #192

wslh wrote: post #63

I posted the same article 1 day ago... but used the https address... https://news.ycombinator.com/item?id=8678439

The dupe detector is left porous on purpose to allow good stories multiple cracks at the bat. A small number of reposts is ok. It's true that who ends up getting the karma on a multiply-posted story is just a roll of the dice. On the other hand, you can stack your long-run odds as high as you want by submitting more and better stories. So it tends to even out in the end.

You're not really stacking your long-run odds any more than you're stacking your odds by playing the lottery a lot. The odds are stacked in favour of anyone who submits a lot and submits early rather than in favour of someone who submits well.

Re: The Case for Slow Programming

#329

Post by dang » Wed, Dec 03, 2014, 8:06 AM UTC

glurgh wrote: post #328

dang wrote: post #192

Earlier quoted context omitted.

The dupe detector is left porous on purpose to allow good stories multiple cracks at the bat. A small number of reposts is ok. It's true that who ends up getting the karma on a multiply-posted story is just a roll of the dice. On the other hand, you can stack your long-run odds as high as you want by submitting more and better stories. So it tends to even out in the end.

You're not really stacking your long-run odds any more than you're stacking your odds by playing the lottery a lot. The odds are stacked in favour of anyone who submits a lot and submits early rather than in favour of someone who submits well.

I'm not sure what you mean by submitting "early", or what experience you're drawing on here (your account has submitted zero stories!), but am pretty sure that the odds favour a user who submits a lot that is good [1] and that the latter is where the emphasis should be. We're also working on systems to amplify this effect, so it is going to get more true with time. The point as far as karma goes is not to be attached to any one post, but rather to play for the long run.

1. What counts as good on HN: stories of intellectual substance that many good hackers would find interesting.

Re: The Case for Slow Programming

#330

Post by collyw » Wed, Dec 03, 2014, 8:56 AM UTC

victorhn wrote: post #244

wellpast wrote: post #76

Earlier quoted context omitted.

I'm not saying that it doesn't take time to build software and I'm not making a case for how to do management. In my decade of experience on different teams and products, the main impedance to productivity has by far been to do with bad code and architectural choices. The justification is always "speed" but my point is that is wrong. It's not speed that is at fault, it's that most software engineers don't know how to…

I am clueless about this, How do you learn to make good architectural choices?

Practice. As well as trying to notice when things work or don't (I have colleagues that see "firefighting" as a normal part of a running system. If something keeps needing attention, it is probably badly written or architected).

Linus said something along the lines of bad programmers worrying about the code, and good ones worrying about the data structures. I think there is truth in this, even though I develop Django database applications most of the time. If I find myself doing too much work at the application level, taking a step back I can usually see a better approach when I rearrange the database.