Sessions are the Achilles heel of every application server.
Michael T. Nygard, Trampled By Your Own Customers (pdf)
Earlier this year I started a big Java development project with my team. I did mostly Rails development for a long time, so when I came back to Web applications in Java I had some expectations. I expected that Tomcat would treat user sessions in much the same way as Rails does; but it doesn’t.
I’d like to share this quote from E.W.Dijkstra:
When the design of the THE Multiprogramming System neared its completion the University’s EL X8 was getting installed, but it had not been paid yet, and we hardly had access to it because the manufacturer had to put it to the disposal of an American software house that was supposed to write a COBOL implementation for the EL X8. They were program testing all the time, and we let it be known that if occasionally we could have the virgin machine for a few minutes, we would appreciate it. They were nice guys, and a few times per week we would get an opportunity for our next test run. We would enter the machine room with a small roll of punched paper tape, and a few minutes later we would leave the machine room with the output we wanted. I remember it vividly because when they realized what we were achieving, our minimal usage of the machine became more and more frustrating for them. I don’t think their COBOL implementation was ever completed.
EWD1303, My recollections of operating systems design
I can picture Dijkstra and his collegues working with paper and blackboards and thinking hard about how they were writing their software. They came into the room and their software just worked. And I can picture the Cobol crew in a furious vicious circle of code-and-fix; their growing frustration and despair. That was about 1960: no books on software design existed back then. For that matter, no books on compiler writing existed either.
Could the Cobol crew have done better? Absolutely. In 1954, the FORTRAN team led by John Backus produced a compiler that reportedly wrote code almost as good as hand-written. How could the poor Cobol crew have done something as good or at least good enough?
My answer: by designing their software. By breaking the thing into parts (modules) and developing each one separately. By using analogies from other engineering disciplines; by using metaphors. I know this is all obvious to us in 2011 as we all know about module decomposition and the use of metaphors and coupling and cohesion. But is it really obvious? Really?
What I see is that modern-day software teams today can *still* be divided in two kinds: the Dijkstra-crew kind and the Cobol-crew kind. Those who are in control and produce reasonably good software within reasonable resources and whose code is reasonably clean; and those who toil away late hours and produce late and buggy software, with no design, or perhaps with an ineffective, we-dont-really-believe-in-it design and crappy code.
Which do you want to be? What will you do to become it?
Great post:
http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours
Re-reading Kent Beck’s TDD book, Ian Cooper recovers some important things that are often overlooked.
This speaks to a very important, in fact, vital understanding that students must have, and it is this: a great many of the teachers of guitar, and a great number of all instructional materials out there, are only useful if you already know certain things, or already have overcome or bypassed certain obstacles. Otherwise, these teachers and instructional materials are actually harmful, they will increase your problems, and, if followed over time, will ingrain those problems more completely into your technique.
Wow. I found this quote in today’s newsletter from Jamie Andreas. I gave up guitar long ago, but I still subscribe to her newsletter because she’s a very good teacher. Let me repeat: she’s a very good teacher. She really cares about how to get to mastery.
Now is this relevant to XP and agile? You bet! The bitter truth I learned is that going head on for XP with TDD and incremental design might not work well, unless the team has a solid enough grasp of the basics of software design. The authors of the Grand Old XP Books were raised in a primordial broth of object-oriented design; they lived and breathed it. Not so for the kids these days: OOD is not fashionable. All we hear and care about is tools and frameworks.
The advice in Rapid Development is always sound: work on the fundamentals!