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

221–230 of 346 posts

Re: The Case for Slow Programming

#221

Post by NateDad »

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…

FWIW, Go namespaces everything by default, so if you import a package called foo, all types, functions, etc from that package are namespaced by foo, i.e. "foo.whatever"

The thing I love about Go's packaging is that your VCS and package manager are the same thing. There's no need to wonder where the code from package foo comes from... because you know you imported it from github.com/jimbob/foo It also means there's no fighting over namespaces, since it's just done by domain name (i.e. I can have the package npf.io/foo because I control that domain, and I don't have to to fight over who gets to use that name).

Re: The Case for Slow Programming

#222

Post by NateDad »

ploxiln wrote: post #208
sysk wrote: post #188

Earlier quoted context omitted.

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

Go's model is pretty good. This is why there's just a single $GOPATH and every package has exactly one location on disk, so even if 100 dependencies use the same subdependency... you only have to update one spot if it needs a patch. And again, this only needs to be done at development time. It's baked in when you compile, and from there on, deployment is just a file copy of your binary. No dependencies during deployment.

Re: The Case for Slow Programming

#223

Post by NotOscarWilde »

Joeri wrote: post #193
wmt wrote: post #179

Earlier quoted context omitted.

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

It's not just that not a lot of science is applied to the craft of programming. It is that many programmers are actively hostile to the concept. For example, the rules of programmers.se forbid asking for statistics. So if you want to know objective facts about the craft of programming, you're forbidden from asking for it on the most popular forum about that craft. When I asked why this rule was in place, it became ap…

> When I asked why this rule was in place, it became apparent that the only real reason was an irrational dislike of statistics.

Can you reference those claims? If I ever repeat this claim, I would prefer to be able to link to the administrators' statements directly.

Re: The Case for Slow Programming

#224

Post by NateDad »

keyle wrote: post #169
cesarbs wrote: post #62

Earlier quoted context omitted.

That sounds awesome, I'll definitely give it a try.

I am afraid a language change is not going to help your burn feeling

I don't know that I agree with that. Tooling bloat was specifically mentioned, and Go is quite good with respect to that.

There's just the one go tool to install, which can be installed just by unzipping a zip file. From there on in, you don't need any other tools. It just uses VCS for package management. You don't need an IDE... the single go tool has support for pretty much every part of the development cycle - compiling, testing, code formatting, profiling... there are no other tools you need to create real deliverable software. I've been writing Go for over two years and still haven't added any other tools to my standard workflow - git and go are the only two commands I type while writing go code. (At work we use a revision pinning tool, but I haven't needed that on my side projects.)

Re: The Case for Slow Programming

#225

Post by Ma8ee »

pekk wrote: post #57
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…

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…

The problem is that anyone who know how to attach two boards with a few nails think they know how to build a house.

Re: The Case for Slow Programming

#226

Post by lmm »

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

Was your flexibility in the right direction? I could tell you exactly the opposite horror story, where an enterprise architect built in a bunch of flexibility that we never used, but we still spent a load of time changing everything as the customer requirements changed. Only we had to spend twice as long because we had to change everything in three places because the "flexible design" required that.

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

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.

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.

Re: The Case for Slow Programming

#227

Post by hibbelig »

vladd wrote: post #199
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…

"swift" might be a close translation.

Yes, my English is less than perfect, but it sounds about right.

Re: The Case for Slow Programming

#229

Post by fsloth »

angersock wrote: post #67

I'll disagree with a few points here. First, I think that the key is a mindset, not an age--I'm the youngest person at my company and yet I'm consistently the one pushing for smarter, smaller, better-designed solutions to our problems. It seems that a lot of people, especially those with an academic background, forget one of the three qualities of a good programmer: extreme laziness. Developers (often younger ones) t…

" if you have one person who "owns" a part of the code, you are inviting disaster and bad design. "

I think we have different definitions of ownership. To me, ownership signifies that a certain person is aware of the history of a particular area of code, is responsible for keeping it in good shape and is usually the go-to person for all modification, or at least code reviews all work done to the code.

This does not mean that they should be the only one who understands it and has the ability to modify it.

I think we both agree that the understanding of the code should be dispersed, so that any other employee can get up to speed with the code just in case the prior owner exits the organization.

I'm working at an organization that some parts of which do development in the "share all" mentality and some of which try to maintain code ownership in the way I described. The code ownership strategy seems to work much better, but, YMMV as always.

When the code ownership is not made explicit, actually there can develop pockets of "accidental ownership" even in the "share all" codebase. Something that only one person has ever touched, and who does all the modifications because all the organization needs is a tiny, quick tweak, and the codebase is already a hot mess after endless amount of these "quick tweaks".

"I really, really wanted to believe that good design mattered, that somehow it had intrinsic value. Sad thing is, it doesn't. BeOS failed. Plan9 failed. Inferno failed. Transmeta failed. Sun and SGI failed. Smalltalk failed. Lisp failed. Erlang failed"

Those all are large scale systems, so I cannot speak for them.

However, in the scale of day to day coding, I've usually attempted applying good design to all of my prodcution code and usually the only feedback I've got from my way of working has been positive. I've shipped on time and the bugcount (for all I know) has been low.

So, based on my experience, I really cannot concur with you.

Perhaps our experience from software development is from a completely different business area. Professionally I specialize in performance critical C and C++, 8 years and counting so perhaps I've not been long enough in the field just yet to witness the fail of good design.

Re: The Case for Slow Programming

#230

Post by maigret »

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…

> "All because agile."

Let me disagree with that one sentence. Martin Fowler has described how design and agile can work together well [1]. What many people describe as "agile" is actually what the agile community names "cowboy development".

[1] http://martinfowler.com/articles/designDead.html

Post reply on HN