* * * * *
                                        
                                “We the willing”
                                        
I'm was still trying to process that the process of our process is to process
the process to ensure the process has processed the process [1] when I came
across this rather insightful comment about the F izzBuzz Enterprise Edition
[2]:

> A combination of wasteful architecture astronomy and legitimate need to
> divvy up absolutely mammoth line-of-business applications among teams with
> hundreds of members operating for years with wildly varying skill levels,
> often on different subsystems from different physical locations, with
> billions of dollars on the line. You can't let the least senior programmer
> in the Melbourne office bring down the bank if he screws up with something,
> so instead you make it virtually impossible for him to touch anything than
> the single DAO which he is assigned to, and you can conclusively prove that
> changing that only affects the operation of the one report for the admin
> screen of a tier 3 analyst in the risk management group for trans-Pacific
> shipping insurance policies sold to US customers.
> 
> The tradeoff is, historically, that you're going to have to hire a team of
> seven developers, three business analysts, and a project manager to do what
> is, honestly speaking, two decent engineers worth of work if they were
> working in e.g. Rails. This is a worthwhile tradeoff for many enterprises,
> as they care about risk much, much, much more than the salary bill.
> 
> (I spent several years in the Big Freaking Enterprise Java Web Applications
> salt mines. These days I generally work in Rails, and vastly prefer it for
> aesthetic and productivity reasons, but I'm at least intellectually capable
> of appreciating the advantages that the Java stack is sold as bringing to
> users. You can certainly ship enterprise apps in Rails, too, but "the
> enterprise" has a process which works for shipping Java apps and applying
> the same development methodology to e.g. a Rails app would result in a
> highly effective gatling gun for shooting oneself in the foot.)
> 

“A comment [3] on HackerNews about F izzBuzz Enterprise Edition [4]”

And how having attended several scrum meetings [5] (at the behest of our
Corporate Overlords) for “Project: Gibbons” (a slimmed down and simplified
version of “Project: Lumbergh [6]”) I can see how this “enterprise
development” is shaking out—it's a form of Conway's Law [7]: “[O]rganizations
which design systems … are constrained to produce designs which are copies of
the communication structures of these organizations.” It's gone from what
should be a simple one week project (If you have the time, and you are a
programmer, you really should listen to this talk. It gets to the heart of
what we should be doing in development but aren't.) [8] (because all it's
doing is looking up a name based upon a phone number and that's it) into a
multi-month project mired in internal bureaucratic overhead. I'm not going to
go into details, but just note that yes, Dilbert [9] is a documentary.

[1] gopher://gopher.conman.org/0Phlog:2018/12/06.1
[2] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
[3] https://news.ycombinator.com/item?id=8779072
[4] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
[5] https://www.mountaingoatsoftware.com/agile/scrum/meetings/daily-
[6] gopher://gopher.conman.org/0Phlog:2018/09/11.2
[7] https://en.wikipedia.org/wiki/Conway's_law
[8] https://vimeo.com/108441214
[9] https://dilbert.com/

Email Sean Conner at sean@conman.org

.