One reason, IBM Websphere. Currently the newest version of Websphere 6.0 is only handles 1.4.2. No idea when 7.0 is out and they’ll finally support it. Unfortunately the picture only gets worse from there. There’s no sightings of a 7.0 beta yet. Next you have a dependency on Rational Application Developer. Turns out RAD 6.0 is based on Eclipse 3.0 and won’t stop spitting errors at you if you dare to use generics or annotations.
Then there’s the nasty boat anchor for us. It turns out Portal Server is based on Websphere 5.1. After about 9 months at least now with Websphere 6.0 out they still haven’t ported it up to Websphere 6.0 even.
I think we’ll actually be able to use Java 1.5 features in maybe two years given the speed of Portal Server updates. The worst part is JBoss, Oracle, and BEA seem to have managed to get at least their main app servers up to the 1.5 JDK by now. You’d think the market leader would at least try to retain parity. The dolphin release of Java should be out by then so we can be two full releases behind at that point.
“No, really the standups worked, even with only 3 people they really helped everyone stay in sync.”
This was one one of my more sarcastic developers (sarcasm and software are so often synonymous) explaining that he actually saw value in standup meetings. Given a general hatred for meetings by your average developer it was nice to get some feedback that someone saw some value in them. I’ve noticed that I tend to have meetings on Tuesdays when the standups are scheduled and the team doesn’t tend to get together on their own and hold the meetings so I’d always taken that as partial evidence they didn’t completely buy into the standups.
So it was nice to hear someone specifically explain that they were valuable to them. I suspect they don’t happen if I’m filling in as the ScrumMaster because there’s still some deference to my management position. I actually don’t think having only 4 standups a week is a big detriment, but it’s always struck me that it does break the rhythm up a bit.
I sat in on the Sprint Planning meeting with some of my developers today. It was time boxed for 4 hours to do higher level estimates, select the backlog items for the Sprint and agree to commit to them. The second meeting will be Monday for 4 hours where the tasks are broken down into 4-16 hour chunks so everything can be planned out in more detail.
As it turned out the meeting only went 1.5 hours which is one of the advantages of time boxing. We already saved 2.5 hours today. Walking back for lunch I saw the QA tester for the project. He explained:
“Heh, I like this whole Agile thing. Nobody hides the fact that we’re just making things up with the estimates at this point.”
It is really nice to agree to be honest about these things. And after the first Sprint the estimates should get better since we have actual experience to work from. It’s nice to be free to admit we have an empirical process instead of something that can be tracked in minute detail on a Gantt chart.
In June of 1979, the Ada programming language became a reality ([SIGPLAN, 1979a], [SIGPLAN, 1979b]). The U.S. Department of Defense set up Ada training classes at West Point, the Naval Post Graduate School, Georgia Institute of Technology, the National Physical Laboratory (U.K.), and the U.S. Air Force Academy in Colorado Springs, Colorado.
At the Air Force Academy, the task of designing a week-long Ada training course fell to Major Dick Bolz and Captain Grady Booch…
It is the second step in Booch’s process (i.e., the development of an informal strategy) that involves what some today would call a “use case.” The “informal strategy,” as Booch originally described it, was in the form of a paragraph describing a solution to the defined problem.
— Be Careful with Use Cases, Edward V Berard
I’m showing my age here, but I came across this mention of Grady Booch as an Ada instructor for the military and was honestly surprised. My knowledge of Ada is very light, pretty much just a few rants from my college roommate about dealing with it in a CS class at Georgia Tech. Indeed when I heard about Adabas a few years ago at a client job at CalSTRS I assumed it was Ada they were talking about and not a legacy mainframe database.
So Use Cases have some sort of strange link to Ada.
Cory Foy has a post on evidence from at least one project that unit tests may be in fact free, as long as you do TDD. The point is that they wrote 35,000 lines of source code for a project and 35,000 lines of test code and they delivered in about 9 months with 8 people. According to some numbers from McConnell this would be pretty good if you just count the lines of source code. If you count the 75,000 overall lines the team performed at an extraordinary level. So in essence the extra quality baked in with unit tests kept them on schedule and didn’t actually add any time to the schedule, essentially making it free. This is similar to the idea I’ve heard from JB Rainsberger and others that everyone believes that:
- You need to go faster to code faster.
- Actually you need to slow down to go faster.