Investments in complexity bring fewer and fewer benefits, until maintenance alone consumes all resources.
http://t.co/CL87QjJNjg
Joe Armstrong on Programmer Productivity
21–30 of 90 posts
Re: Joe Armstrong on Programmer Productivity
#22The corollary to a) that I deal with all the time is third party integrations that are poorly documented and that after some time X start magically working even though the third party changed nothing on their side (according to them). Management always thinks "We've integrated things with this vendor before, it will be a snap to do again on a totally different endpoint" and this is never the case.
My last job was in an agency that used to build websites for a fixed cost. After a few years of doing it we changed the policy so that integrations were charged as time and materials. You just can't judge how long it's going to take when you have to deal with an external organisation. Hell, one of the projects I was working on before I left (a year ago) was started 2 years ago - and it's still going on. It's just a s…
Integration is one of the biggest problems because there are the most unknown unknowns, to quote Rumsfeld. You don't know what spontaneous changes will happen, and you frequently can't control the resources on the other side.
Re: Joe Armstrong on Programmer Productivity
#23I rewrote a (~10k lines) C++ app to erlang back when I was learning erlang, and saw a ~75% reduction in lines of code. http://www.metabrew.com/article/rewriting-playdar-c-to-erlan... I expect the 'N' value varies wildly depending on what you are building, and whichever language you are comparing against.
Did you try to rewrite the app in C++ and look on how many percent reduction you get from that second try? I think it’s fair to compare that second app in C++ with the rewrite in another language since a rewrite will likely always be shorter independent of the language.
Good point, but it's also not quite a fair comparison to go back and forth between implementation languages.
Changing the language changes your thinking about the problem. If you translate a program from erlang to C++, the result might be shorter and more reliable than if the first version is in C++ and you rewrite it in C++. It also might not be, of course, but the fact that it could be muddles the comparison.
Re: Joe Armstrong on Programmer Productivity
#24 The problem is we don't do similar things over and over again. Each new unsolved
problem is precisely that, a new unsolved problem.
Re: Joe Armstrong on Programmer Productivity
#25The corollary to a) that I deal with all the time is third party integrations that are poorly documented and that after some time X start magically working even though the third party changed nothing on their side (according to them). Management always thinks "We've integrated things with this vendor before, it will be a snap to do again on a totally different endpoint" and this is never the case.
Exactly. Same for non-commodity hardware. Come to think of it, even true for commodity hardware.
Re: Joe Armstrong on Programmer Productivity
#26this is partly why I advocate a slow code movement similar to the slow food movement. instead of sprinting I would like to walk to the destination, avoid the pains of broken ankles and repairing shoes whilst running in them. I would like to explore to find a sane and reasonable approach and not be driven by artificial deadlines guessed at three months ago but by todays business need. i would like to actually be measu…
Yes, where can I sign on?
Re: Joe Armstrong on Programmer Productivity
#27Nice post although I disagree that 30 years ago stuff mostly worked. That's not how I remember it but I guess his main point was that there was a lot less software then.
Re: Joe Armstrong on Programmer Productivity
#28I've often wondered what the software development world would be like if we used prototypes. Experimental hacking seems like a cut-down version of this concept.
But what if we actually built things that we already agree in advance to throw away? Maybe even start from two or three different plausible designs, and push on each one for a while until one seems to be winning? Then rewrite it, learning from the other contenders and from the prototype itself, all before shipping.
The obvious answer is that it would take too long. But I'm not so sure. They say designing software takes too long, also, but when I spend a few weeks designing, the implementation ends up going smoothly and hitting the target. Usually the features that are designed thoroughly at the start of the release hit the target, and other "quick" features that are added in later, sans design, take longer than the designed features and end up pushing the release out. Any overruns or missteps in the implementation of the well-designed features seem insignificant in comparison to things that skimped on design work.
Re: Joe Armstrong on Programmer Productivity
#29this is partly why I advocate a slow code movement similar to the slow food movement. instead of sprinting I would like to walk to the destination, avoid the pains of broken ankles and repairing shoes whilst running in them. I would like to explore to find a sane and reasonable approach and not be driven by artificial deadlines guessed at three months ago but by todays business need. i would like to actually be measu…
I think the PostgreSQL community gets this right. The only deadlines are if you want your feature in the upcoming release, or if you can wait another year.
Seems to be paying off quite well. What other database can ship reliably every year with major new features and all kinds of improvements on many axes? And people still say the code is readable and the reliability is solid.
Re: Joe Armstrong on Programmer Productivity
#30I've often wondered what the software development world would be like if we used prototypes. Experimental hacking seems like a cut-down version of this concept. But what if we actually built things that we already agree in advance to throw away? Maybe even start from two or three different plausible designs, and push on each one for a while until one seems to be winning? Then rewrite it, learning from the other conte…
This is a well-discussed concept already - see the concept of "Spikes" in Agile development, or to a lesser extent, the idea of "Tracer Bullets" from The Pragmatic Programmer.
Of course, what's done in practice tends to differ, unfortunately.