More on asshole driven development
Hey folks – apologies if you’ve had problems accessing the site. The last blog post on asshole driven development was a hit. I’ve had more traffic on that then anything I’ve written in history.
If you want more commentary and painfully funny methodologies there are additional comment threads on the three major drivers of traffic: Digg & O’Reilly Radar, And Reddit.
Tiff Fehr has put together an analysis of the different methods and comments to date. Worth a look.
There are still about 120 comments in the queue (out of almost 400 total) – if yours doesn’t get posted, please don’t call me an asshole :) Many of them were redundant, bizarre or beyond my level of comprehension. They’ll all get read, but at 100+ comments I’ve got to filter some stuff out.
Not sure which of you got the run going, but thanks to all who passed my writing around.
How about ADDD — Attention Deficit Driven Development, where people work on tasks until…um…what were we talking about?
I think you get that many comment because you describe the reality of many software projects. I hope you include the development processes here in your book “The Art of Project Management”. It would be invaluebale for project managers to know these processes, so they know when something is wrong. And know why people dont listen to them anymore.
Totally agreed.
The truth is that there is nothing to worry about.
Especially when you describe the pain of software development.
Damn. I think we got a couple of these models going on at my project. It sucks to be me. Or is everybody’s project run like this?
There’s EDD (Error Driven Design) which constantly took place at a former company. Tech support tickets and “this is broken” “that is broken” dictated what we worked on. I did not stay there long needless to say. We were not allowed to ‘analyze’ and ‘design’ – just code it please and NOW. Simple-minded MANAGERS are the most to blame, managers that don’t understand that software control is serious and complex.
I’m an old timer programmer, now retired, who started in assembly language on minis and mainframes in the early 80’s. We learned Yourdon and DeMarco methodologies (mostly done by hand with pencil and paper). In the late 80’s they started pushing Object-Oriented Programming (OOPS), which was not ready for prime time in those days, as the machines were too small and slow and the compilers for ADA (the first OOPS language other than SmallTalk, I guess) not complete. Having programmed on the bare metal, so to speak, up to that time, I figured we needed MOPS (machine-oriented programming). It’s still not a bad idea, as languages like C++, C#, and LISP, with new objects and methods constantly being defined, we are running into the Write Only Coding problem. It doesn’t matter what methodology you use, because when it needs to be modified, nobody can figure out what you did, so they just start over.
This doesn’t refer to development but to business plans as I see them. Too Much Science (TMS) where you need a PHD and a hat with a propeller to understand. Jargony, patents, formulas etc.
Too Much Brain Damage (TMBD) where you have to think too hard to understand. Generally a bad sign because if it is too complicated, generally not thought out enough. Business is surprisingly simple. Make profit.
Great page. The real dirty f*ckedup truth of softwaredesign…