Scott Berkun posts broken but commonly used dev methodologies

Discussions

News: Scott Berkun posts broken but commonly used dev methodologies

  1. Scott Berkun has posted "***hole driven development," saying that "if we’re going to have dozens of models we may as well have some that are honest, however cynical, to what’s really going on much of the time." The five he lists are:
    ***hole Driven development (ADD) - Any team where the biggest jerk makes all the big decisions is ******* driven development. All wisdom, logic or process goes out the window when Mr. ***hole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway. Cognitive Dissonance development (CDD) - In any organization where there are two or more divergent beliefs on how software should be made. The tension between those beliefs, as it’s fought out in various meetings and individual decisions by players on both sides, defines the project more than any individual belief itself. Cover Your [Arse] Engineering (CYAE) - The driving force behind most individual efforts is to make sure than when the s*** hits the fan, they are not to blame. Development By Denial (DBD) - Everybody pretends there is a method for what’s being done, and that things are going ok, when in reality, things are a mess and the process is on the floor. The worse things get, the more people depend on their denial of what’s really happening, or their isolation in their own small part of the project, to survive. Get Me Promoted Methodology (GMPM) - People write code and design things to increase their visibility, satisfy their boss’s whims, and accelerate their path to a raise or the corner office no matter how far outside of stated goals their efforts go. This includes allowing disasters to happen so people can be heroes, writing hacks that look great in the short term but crumble after the individual has moved on, and focusing more on the surface of work than its value.
    Scott ended by asking for additional methodologies in the same vein, with the result that Tiff Fehr put together "Tech Development Styles for Cynics," with some gems of its own: a "run out the clock" methodology (with which Your Humble Editor is sadly familiar, as a client) and Seagull Management ("the seagull manager flies in, makes a lot of noise, craps on everything then flies off again leaving a big mess behind"). Chances are most of us have run into these "methodologies" in some form or fashion, and knowing something inefficient often provides perspective on what's right about alternatives, so it's not only amusing but somewhat instructive to check these out. Feel free to mention examples you've run into - and it'd be interesting to see how these styles were neutered - erm, "fixed" - in practice.
  2. My co-workers know I'm an expert at ADD. Who needs scrum or xp when my definition of teamwork is a lot of people doing what I say.
  3. You forgot a methodology that goes with ADD - the 'Design by conduct' methodology. In my team we greatly respect this approach, following our Dalai Lama's (A in ADD) techniques: - first we apply Simpleton pattern to ensure that our singleton resources are simple; - then, every non-prototype component needs a command, thus we apply 'Commando' and introduce a lovely coupling with 'Visitor from Hell' patterns. - after the 'construct' has been made, we randomly apply 'Blinder', 'Chain of possibilities', 'Compromise' and 'Detonator'. - the server side is readly, we build front end using the MVC (Modal-Viewed Components) and ship the project with documentation from doc-generator. I hear the hype word to use is 'agile', so the 'design by conduct' is an agile methodology, W3C compliant, SOA enabled and ESB aware. Call now or any time. (c) Shamelessly stolen from http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns
  4. I hear the hype word to use is 'agile', so the 'design by conduct' is an agile methodology, W3C compliant, SOA enabled and ESB aware.
    You forgot 'POJO'.
  5. The one that is mentioned on Tiff Fehr's blog: 'The Process Development' is real. I lived it. And the association to 6 sigma is also my experience. I literally worked at a place where having the proper sign-offs was vastly more important than having a working result. Actually the whole thing was a joke where empty documents were submitted per 'tollgate' requirements and approved. I can't count the number of times I went into look at some documentation for an existing solution and found the exact same templates. The process was probably the impediment to a successful project in the department. More processes were continually built around the existing processes in order to 'ensure' compliance making it harder and harder to actually succeed at an effort. Eventually the solution was to outsource (development is so expensive!) and add more process which the contractors invariably violate whenever possible (because they aren't stupid.)
  6. Hmmm, DBD sounds all too familiar.