Hacker News new | ask | show | jobs
by gruseom 5350 days ago
Language is clearly not the whole solution, only part of it. The greater part is, I suspect, psychological and social. We have yet to come to terms with the relationship between software development and how humans function. Given that code is written by humans for humans, that's a fatal omission. Yes, there have been attempts to talk about this (Weinberg, Peter Naur, the better parts of agile) but they're the tip of an iceberg.

(p.s. Edited for brevity. I always do that and never bother saying it, but in this case there was a concurrency conflict because someone downvoted the bloated version. Mea culpa.)

1 comments

It's a very interesting point but personally I couldn't disagree more. While being human means we'll never get rid of the chaos, I think a new paradigm can take us a huge way towards managing that chaos and abstracting it away to a great degree.

I remember a lunch I had with Kent Beck in Zurich in 1998 (I think) and I was all set to pounce on him with this idea I had of a new approach and he instead pounced on me first with XP. I was utterly unconvinced, not because he didn't make a fantastically convincing argument, but I was -- and am -- convinced the failure stems from somewhere else.

You're more optimistic than I am. I think the limiting factor in software development is the human brain. It has two critical limitations: an individual mind can only handle so much, and different minds don't compose easily. Yeah, XP was absolutely an attempt to address that. Did it work? Not in my book. It doesn't take the creative process seriously enough - not even close. Instead it regards creative minds as something to be harnessed as a resource (a nicer way of saying exploited). My body rejects that.

Another way of putting this critique is that XP is designed to work inside existing companies that are incapable of tolerating the forms of organization needed to produce software well, when what we ought to be doing is starting new and much smaller organizations, which in the local dialect I believe is called "startups". Of course it's not that easy, because once startups begin to grow, they bring back the old organizational assumptions. But that just means we need more deviant startups.

You, on the other hand, think there exist paradigms of abstraction that can fit the complex systems we're trying to build well enough to make the process tractable. I hope you're right. Certainly some such forms are better than others, so others could be better still.

How do you propose to demonstrate it?

That's a great argument. We seriously, seriously need to go for a beer.

You've summarized my argument nicely.

How to demonstrate it? Are you asking me to put my money where my mouth is? :-) Good question. I'm working on it. For example, we need to query code. I want to see all aspects of this portion of the UI. We should only look at code in layers, as accounting systems do. For one. I could go on, but I'll leave that for sometime over a beer.