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

241–250 of 346 posts

Re: The Case for Slow Programming

#241

Post by adwelly »

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…

Deliberate Programming might be a better term; it encompasses the idea of steady progress, and solid intent. - update - I see this has already been suggested. Still like it...

Re: The Case for Slow Programming

#242

Post by runeks »

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…

> 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.

Most likely, not a lot of things compare to building houses in all aspects.

The point is, if developers are having problems wrt. scaling, then we need to build tools that abstract away scale. Define a language that allows the runtime to auto-scale, depending on load. As far as I can see, it's "just" another engineering challenge, not essentially different from figuring out how to make a skyscraper withstand heavy winds.

Re: The Case for Slow Programming

#243

Post by moconnor »

jsilence wrote: post #180
rapind wrote: post #168

Earlier quoted context omitted.

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 s t done zügig.

This is true; it's also true that Things Work here. Processes, equipment, social organizations.

To get your fishing permit you will need to provide all the right bits of paper and stamps, no exceptions.

The flip side of this is that if you follow a set of precise, unambiguous instructions you will get your fishing permit.

Source: moved from UK to Germany 8 years ago.

Re: The Case for Slow Programming

#244

Post by victorhn »

wellpast wrote: post #76
pekk wrote: post #57

Earlier quoted context omitted.

It takes a certain amount of time to build a house (that will be durable and to code) no matter how much people want "skill sets". If it takes a longer time than management wanted for something to be built, that isn't necessarily because "skill sets" are lacking. If the product is shoddy, that is probably not because the team lacked the magical ability to make sound products instantly, but because the team was rushed…

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?

Re: The Case for Slow Programming

#245

Post by Spearchucker »

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…

"Was your flexibility in the right direction?"

Yes.

"Why would your way have been different?"

Because I had a form that created a form.

You know, a lot of failed projects that I've worked on were my fault, because I was that guy. The guy who questioned the seasoned greybeard. The guy that knew JavaScript is the only answer. That agile is the only way to manage development. And if agile didn't work, it wasn't because agile was a bad choice, but because you were doing it wrong. That document databases can replace relational databases. That dependency injection is good. You get the idea.

What sounds good, looks good and feels good is sometimes, and sometimes very often, very bad.

The thing someone in their 20's doesn't know is that people in their 20's don't know. People in their 30's that are even vaguely in touch with themselves start realising they don't know. In my late 30's I questioned whether I'd wasted my entire career by not learning anything. Today I just know. I know an idiot before he opens his mouth. And I see a bad design decision happening when the team is assembled, before anyone has even started to design anything. That the 5th sentence in the 5th paragraph of this post is badly structured. Most importantly, today I know when I don't know.

I still fuck up. Spectacularly so, sometimes. But not as often as 30 years ago. And not as often as last year. Or last month. I happen to have been right in my post above. Hindsight proved that.

Re: The Case for Slow Programming

#246

Post by spacemanmatt »

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.

Career vocational software craftsman here. Academic background in math and science have served me well as I self-taught all the CS and application development skills I have collected over the years. Vocational training probably would not have hurt, but I don't see how it could fit a traditional curriculum; I have only accelerated my pace of learning as the internet and quality of free tools and instructional material have grown, and I attribute that entirely to the buffet nature of online training.

Re: The Case for Slow Programming

#247

Post by GFK_of_xmaspast »

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.

Maybe if all you ever want out of your programmers are fart apps and web forms.

Re: The Case for Slow Programming

#248

Post by dschiptsov »

klibertp wrote: post #238
dschiptsov wrote: post #205

> 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 pro…

> In "old times", [...] being mostly scientists Citation needed. For every scientist involved with computers in "old times" (at least after personal computing took off) you get easily 10 hobbyists, enthusiasts who actually built stuff.

There are AIMs (lots of them) for example. And besides MIT and Stanford ans CMU there were also research facilities staffed with scientists, like Bell labs, Xerox PARK, etc.

In early programming (Lisps, pre-winter AI, early OO and pre-OO languages, UNIXes) have been done by much brighter people than in modern J-world.

Re: The Case for Slow Programming

#249

Post by spacemanmatt »

michaelochurch wrote: post #148
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…

The term "agile" deserves a preceding apostrophe, as in 'agile, because there are two letters (the 'f' and the 'r') being trimmed. I fucking hate that nonsense. It's a total scam.

I hate that the term has seen total dilution. I have been on outstanding teams that called their methodology agile, but it was an adjective at the time. In that era.

Not the fault of the word, though. I'll keep using it.

Re: The Case for Slow Programming

#250

Post by einhverfr »

duncanawoods wrote: post #232
einhverfr wrote: post #145

Earlier quoted context omitted.

I am not so sure. The point of "slow programming" is the same as "slow food" and "slow democracy." I think you have to see the three together. The point is to slow down, deliberate, and then do. That doesn't mean long iterations, nor does it mean deferring progress. It means ensuring solidity of the progress as you make it. I once interviewed for a job at one of the most recognized and big Perl shops in the world and…

Yep - there are benefits to a slogan being counter-intuitive because the whole point is to challenge the intuitive way of approaching a problem and making you see it anew. In the reverse case, facebook's "move fast and break things" works because it suggests you move fast enough to dare breaking things to try an overcome the caution that holds people back from doing great things. In this case the equivalent slogan mi…

This is also why I don't think moving faster is almost always better. There's a certain point at which moving faster slows you down.

A better way of saying it might be "optimize your progress over the next 10 years, not over the next week."

I think there is a false choice usually presented between agile, move fast and break things, vs old waterfall approach. I don't think waterfall is the right alternative. The waterfall approach is really difficult to get right because to some extent it insulates design from coding. The integration of these two is something that agile gets right.

But what agile gets wrong is in de-emphasizing design too much. Design is important, and it is important regarding long-term progress. And if you don't design, you will pay for it a hundred times over. But the best design is where technology is designed bottom-up and UX is designed top-down. Done right, this integrates design into coding but it also emphasizes design and code contracts.

Post reply on HN