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

101–110 of 346 posts

Re: The Case for Slow Programming

#101

Post by Filthy_casual »

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…

As a beginner I recall myself asking other programmers "is using pen and paper cool before writing any actual code?" and they giggled before nodding in agreement.

I had this false expectation in my head that when programmers tackle a new problem (be either writing a small program or solving a challenge) they're able to think about it for a few minutes then straight up write code and if I can't it's because I suck and this job isn't for me.

Then I realized that what I expected was unrealistic and the "no pen and paper" stage only occurs to people who already met the same or similar challenge before and can recall even the slightest hint of what they did back then.

Re: The Case for Slow Programming

#102

Post by mattxxx »

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.

Re: The Case for Slow Programming

#103

Post by Spearchucker »

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 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). My proof of concept took 4 weeks, and on the basis of that I estimated a 6 month project. When I presented the idea it was viewed as being too complex, and therefore too risky.

So the dev team just started hacking it out, field by field, and saving the whole form into Mongo as a single, nested document. Guidance was hard-coded into the HTML. It was fast, and at the start everyone was awed.

Of course soon after the customer decided that the guidance for the printed form wasn't appropriate for the online version. And of course the customer wanted to analyse data across all forms. What was a 6 month piece of work took 3 years. And still no ability to analyse data nested in Mongo documents. Any change requires hours of re-work, regression tests and sign-off.

All because agile.

In my 20's I'd have been emotionally destroyed. Ego like an aeroplane into the side of a mountain. No survivors, call of the search. Happily I'm in my mid-40's. I know better, and I know better than challenging an inexperienced project lead that has too much authority. So I move on. There's always a project that's more suited to my style of work (slow).

Re: The Case for Slow Programming

#104

Post by math0ne »

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…

I see no correlation between typing fast and being a good programmer.

I mean how much do you even have to type to program, if I produce a page of good code in a day, thats a good day, and it doesn't take long to type.

Re: The Case for Slow Programming

#105

Post by jaunkst »

Speed, is a constant demand. The rate that we are creating new frameworks, languages and platforms is an all time high. We toss them away as quick as we build them, by the time its reaching mainstream adoption we are refactoring the core, and expecting developers to adopt the changes before they master the first mature iteration. Born to die software is here and its going to cause a massive fracturing. If we adopt reverse compatiblity maybe we can offset the repercussions. I expect my code to start to deprecate in atleast 6 months in some manner.

Re: The Case for Slow Programming

#106

Post by EdSharkey »

Lack of design in software nowadays was cited as a problem in the post. I agree, and I think there's a lot of not-classically educated hands out there that wouldn't know a good design document from bad. Nor would they have any practical knowledge of a combination of: how to structure code in large code bases, test their code, converse about/apply software patterns, document their API's for public consumption, RAII, SOLID, TDD, etc. So, I think there's little hope for improvement in software quality/design/success metrics/etc.

Big up-front design only satisfies document weight tests and typically does not stay up to date with the software. So, just simply saying "we need more design" is not going to get us anywhere but hell.

Self-documenting code is a nice idea, but scales only so much in a large codebase. UML is a bear to produce and maintain, and I only really like it in whiteboard discussions, not actually drawn in a tool.

Wikis devolve into a mess of disconnected ideas.

Successful teams I've been on tend to rally and organize designs around the already generated documentation (like JSDoc or JavaDoc), but those docs often only focus on the user-facing API's and leave the internals as a partially documented wasteland.

A few teams I've been on had a scribe, which was sweet, but not usually.

What patterns of design and documentation actually work well for you in real-world, large project/team scenarios?

Regarding needing an aged "adult in the room" to guide the fledgling developers to glory, as I think the OP suggests is an answer to the problems ... Well, in my many experiences where imparting wisdom from on-high was the goal, that has been a miserable failure. It was all because said "senior architect" or whatever the title was invariably only cared about blessing random big decisions randomly/destructively and had otherwise checked out to walk his dog after lunch and otherwise coast during his pre-retirement. All I can say is, God bless 'em.

I do NOT count on age as a factor, only that a developer has reached a certain point of experience in their career. What I DO count on is one person who can enforce a clear vision with passion. Who holds the torch for your team? Is their grip shaky or firm? Where are we headed? Are we headed there with conviction? Does the end goal still seem plausible to all hands after every step we take? If you have proven you've got the chops and can back up all your assertions with creditable past successes and/or literature, you can rule your team and demand excellence - YOUR excellence! Pick a darn direction and let's go! I have total respect for that someone that has a coherent vision AND can communicate it.

Agile methodologies sound plausible to address design and software productivity issues, but I have yet to see exceptional results from an agile project vs waterfall. This is probably just because software is a hard thing to do well in any case, and is subject to political winds, funding, ineffective product owner, etc.

Re: The Case for Slow Programming

#107

Post by mattxxx »

JackFr wrote: post #14

He makes a reasonable point, but this piece is largely a strawman. And > For the same reason that many neuroscientists now believe that the fluid-like flow of neuronal firing throughout the brain has a temporal reverberation which has everything to do with thought and consciousness, good design takes time. is just pure nonsense.

Yea, the article kinda reads like "bad programmers are bad, and I'm a code master, and the kids don't program like me, and they're bad-bad-bad. their fast is so slow. my slow is so fast."

It's weird how he like does this thing where he equates their fast with thoughtlessness, and his slow with actual fast.

That being said, I'm all about white-boarding, project planning, and clearing out dependencies, but if an engineer is slowly coding something without any deliverables, chances are their going to hit a wall near the deadline. I've seen this happen too many times.

Re: The Case for Slow Programming

#108

Post by edpichler »

Really liked this part: " And the latest clever development tools, no matter how clever, cannot replace the best practices and real-life collaboration that built cathedrals, railroads, and feature-length films."

Re: The Case for Slow Programming

#109

Post by justincormack »

AgentIcarus wrote: post #92
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…

This seems similar to michaelochurch's thinking about 'guilds' - which I guess is a precursor to formalised 'engineers' or master craftsmen, which is something Software 'Engineering' seems to be in dire need of.

I recommend Richard Sennett's book The Craftsman, which talks about both the history of craft and software.
Post reply on HN