Subscribe
Posted on January 31st, 2006
Ron Jeffries just announced that he will be the keynote speaker at the upcoming Waterfall 2006 conference with an intriguing keynote entitled Extreme Programming Uninstalled. From the conference page:
Feedback, we now see, is the problem, not the solution. How is it possible to get anything done if all the time you’re looking for, listening to, and – worst of all — Responding to Change? We have only to look at the present international situation to understand how useless feedback is, and how powerful the strategy is of setting a course and sailing it. It works for our leaders: it will work for us. We can set our course into a Contract, then give the Customer what he needs. Their Collaboration isn’t needed. What is needed is for them to accept what we, their leaders, provide for them. In this context, I must admit that XP and Agile had one thing right: there can be no Negotiation.
Additional seminars include:
- The Joy of Silence: Cube Farm Designs That Cut Out Conversation by Alistair Cockburn
- Introduction to Dogmatic Programming by Andy Hunt and Dave Thomas
- Testing: Saving the Best for Last by Lisa Crispin
- FIT Testing In When You Can; Otherwise Skip It by Ward Cunningham
- Avoiding the Seven Pitfalls of Lean by Mary Poppendieck
Personally I’m bummed because I don’t think I’ll be able to get my employer to send me to it and Agile 2006. Then again, with the ability to clearly lay out the problems, maybe these waterfall guys are on to something.
Posted on January 21st, 2006
A break from development a bit here, but in getting settled down into the new place, one of the things I decided to go ahead and do was use a Monowall box as my primary firewall. For years I’ve been using a Linksys Wireless router, and it’s still serving it’s purpose in Charlotte until we get the rest of the house moved up.
The biggest advantage to using Monowall for me is the ability to set up a VPN server using IPSec or PPTP. It can host the server itself, which is a nice bonus. With a PPTP VPN in place, I can connect from public access points, and still know my traffic is safe.
Setting it up turned out to be a breeze. First I hooked Monowall up with my cable modem as the WAN and my local network as the LAN. I made sure everything was passing traffic to the internet, which it was. Next, I went into the Monowall configuration screen to VPN->PPTP. The page can be broken down into four sections:
Enabling PPTP
Here you just mark that you want to enable the PPTP server. Optionally you could have PPTP connections redirected to an existing PPTP server if you have one internally.
Server addresses
Here you specify what address you want the PPTP server to use internally, and the address range you want to assign to connecting clients. In this case PPTP clients will get an IP from 192.168.0.112 – 192.168.0.128
RADIUS Authentication
If you have a radius server you want to use for authentication, you can enter that here. If not, when you finishing setting up the connection a Users tab will appear that will let you specify authentication.
Encryption
Finally, I enabled 128 Bit encryption. Since we’ll be using XP to connect, I know that 128 Bit is built in.
You’ll also notice at the bottom of that last screen shot is an important note telling you to enter a firewall rule for PPTP clients. Luckily they make this easy too. Once you’ve save the rule and added users, head over to the Firewall->Rules page and add a new rule. My PPTP rule looks like:
And that’s it! To connect to it, I simply set up a new connection using the wizard in XP, pointed it to my server, and logged in. I tested it internally (from the LAN) first, and then tried it from an outside connection.
Monowall is a great little firewall that happens to provide some great capabilities as well. If you need VPN access, hopefully this helped you get it up and running.
Happy surfing!
Posted on January 21st, 2006
Let’s face it. Software we build is going to have bugs. Anytime you are writing a large system in the face of changing requirements, something isn’t going to work. It might be that a requirement wasn’t met, or changed during development. It might be that a spec was misunderstood, or that we as developers didn’t immediately stop and ask the customer when we had a question. Or it might just be that we introduced a defect into the system because, heck, that’s what we do sometimes.
Since we know we are going to have bugs, we want to have something in place to keep track of them. In some shops this might be a spreadsheet, or a bug tracking program (like FogBugz or OnTime), or a stack of red index cards. We’ll want to make sure we track things like reproduction steps, the error message, date and time, and other relevant information (maybe hardware, browser, etc).
However, there is one key piece of information that perhaps shouldn’t be captured – who created the bug. “Surely you jest!” one might say. Why wouldn’t we want to track defects by developers?
Well, why would we /want/ to track bugs by developer? It all comes down to metrics. What team wouldn’t want to be able to point at a pretty chart of all kinds of crazy metrics and say, “This is where our problem is, let’s get it fixed”.
But, is that what really happens? Several months ago I observed a project which was a bit vague, and the exact requirements of what was trying to be accomplished were difficult to nail down. The developer on the project was ultimately fired after not being able to deliver it.
Looking at the metrics for the project, it was easy to see why the developer was let go. He wasn’t accomplishing enough. He had “enough” time to figure out what needed to be done. And in the fast pace environment that it was, if he was having trouble with that, well, we could all sleep better knowing that he wouldn’t have made it in any of the other projects.
Except…
Before he was put on the project, 4 or 5 other developers had worked on it. All of them had difficulty trying to nail down the requirements, get a clear direction, or deliver a product. All of them were ultimately moved to other projects.
I bring this up because of a recent quote I read in Lean Software Development:
The vast majority of defects have their root cause in the development systems and procedures, and trying to attribute defects to individual developers is a case of shifting the burden. We are not looking for the root causes of the problem if we trace defects to individuals; rather, we are hiding them.
We are hiding them. This resonated with me. How often have we fixed a bug, knowing that we are merely sweeping the root cause under the rug, hoping it doesn’t happen again, rather than figuring out what caused that bug to happen in the first place, and fixing it. Granted, we may not be able to stop the root causes of every single defect or bug, but I’m sure developers can certainly do better than what they do now.
So, in the above example, maybe that developer didn’t fit in. But maybe there is a root cause, a symptom of a greater sickness, that needs to be addressed. All the xUnit tests in the world won’t help you if you can’t communicate with your customer, and all the communication in the world can’t help if we still can’t figure out what needs to be done, or what it even means to be “done”.
Let’s figure out what really is wrong, and fix the problem. That’s what makes us agile, and succesful. Fixing the symptom just hides the others, and only makes us sick. And I’d rather use my time off to go to the beach then lie in bed, wouldn’t you?
Posted on January 21st, 2006
A recent post by William Pietri on the XP list caught my eye:
Alas, I don’t have the data Brad is looking for on requirements gathering, but I did just happen to come up with some data on that eternal novice XP question: Doesn’t writing all of that test code slow you down?
I just ran the code from a previous project through LOCC:
http://csdl.ics.hawaii.edu/Tools/LOCC/LOCC.html
This is from a pure XP project, a Java-based web application. Total lines of code:
Prod: 34961 LOC
Test: 35176 LOCI haven’t checked exactly, but this was about four developers for 8 or 9 months. Looking at numbers from Steve McConnell’s Rapid Development, and assuming that web applications are more or less like shrink-wrap apps, he has three sets of schedule numbers for 35 kLOC:
shortest possible: 7 months 44 developer-months
efficient: 10 months 39 developer-months
nominal: 12 months 71 developer-monthsSo counting only production code, we did well, slightly beating the efficient schedule. But what if we count the test code? At 70 kLOC, the numbers look like this:
shortest possible: 9 months 120 developer-months
efficient: 13 months 100 developer-months
nominal: 16 months 175 developer-monthsSo assuming McConnell’s numbers are in the ballpark, there are two possibilities. Either we were two or three times as good as the best teams in the source data, or test code is essentially free. Personally, I think it’s the latter.
Posted on January 9th, 2006
An interesting thing happened today. I’ve started a new position with a great company. Though I’ll be working out of Columbia, MO, they flew the team out to D.C. to the headquarters for the project kickoff. Last night and today has been a whirlwind of information, getting a fast-tracked overview of their existing systems and development before beginning the meetings today through wednesday on the new effort. But one thing stood out above all the others:
TLAs
What are TLAs? Three Letter Acronyms. Actually, to be fair, some of these were more or less than three letters, but between yesterday and today I’ve been hit with no less than 19 new acronyms I have never heard before or that are specific to the business. Yes, 19 in about 12 hours.
Which brings up a good point. If you are in a meeting, or development conversation, and a TLA, or other word you don’t know, gets thrown around, be sure to stop at the nearest point and ask the speaker what it is. For example, if someone says they use XP are they referring to Microsoft XP or Extreme Programming? Maybe you can tell from the context, but it never hurts to ask. Which is how I ended up with about 5 pages of notes, with quite a bit dedicated to defining acronyms.
Whether it be XP, TDD, JSF, RTF or many others, what’s your favorite TLA?