Matt O’ Rama

I’m Number 1(96)!

Top 200 Blogs for Developers (Q2 2009)

My former fellow co-author on AgileSoftwareDevelopment.com, Jurgen Appelo, periodically compiles a list of top blogs for developers. This time around, he did a Top 200 and I was surprised to see this very blog at #196! If you clicked over here from there, welcome! Since the list came out on the day I did my first post in a month (!), I’ve been self-shamed into posting more.

I’ve been working a bit with JavaFX so I’ll be posting about that and we just started on our next big project at work so I’ll probably be posting about that as well. On top of those topics I’ve made a list of important books I need to work through to help my Java programming so I’m planning on writing about that process. All in all, lots of geeky goodness to come I hope.

Responsibility

Since I think the word “architect” in a software context has taken on all sorts of horrible connotations (it conjures up images of people who draw boxes and arrows but don’t actually write any code themselves), I tend not to use it personally. Instead, I tend to think of my role on the team as being the guy who should be blamed when things don’t work. Not the guy who should be blamed when something he did doesn’t work, but just the guy to blame, period.

from Taking Responsibility by Alan Keefer on the Guidewire DevBlog

I was glad to see this article get some links from people like Kent Beck on twitter. I read it because Guidewire is a company I’ve worked with very closely (as one of our vendors at my job) for the past 2 years but I’m happy to see it getting read outside the circle of Guidewire customers. I’ve really admired what I know of the technical group at Guidewire and have angled numerous times for a job there. I’ve never met Alan and we don’t use the product he’s the architect on, but I liked this post a lot.

I’ve always thought the job of a manager is to take responsibility for their team, whatever that means. If somebody needs help, the manager needs to help. If there’s political corporatey nonsense going on, the manager is responsible for protecting their people from that. If something doesn’t get done, the manager should be the one taking responsibility for it with the higher-ups. Then if somebody on the team screwed up, it’s the manager’s responsibility to take care of it with that person. Managers that don’t take responsibility are not only not doing their job, they’re actively harmful to their team.

Of course, non-managers should be responsible to themselves and their team as well. I take care of my own stuff at work, but I also try to take care of things the team needs if they aren’t getting done. I’m not a manager but sometimes people just need to take over and get things done. We’re about to start a new project and we have some infrastructure projects that need to do. I could just wait for somebody else to do them or complain that we weren’t given time for them, but I got a whiteboard and started making a list, as well as scheduling a meeting with the parties involved to get a plan for putting these things together. I take that responsibility for my team because I know they would (and have) taken on things for me when I couldn’t. We’re all in this together and if any of us can take on things for the good of the team, we do.

Geek Humor

1936 – Alan Turing invents every programming language that will ever be but is shanghaied by British Intelligence to be 007 before he can patent them.

1936 – Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.

1940s – Various “computers” are “programmed” using direct wiring and switches. Engineers do this in order to avoid the tabs vs spaces debate.

from “A Brief, Incomplete, and Mostly Wrong History of Programming Languages”

hahahaha. Except for the part about Perl.

The Management Myth

The strange thing about my utter lack of education in management was that it didn’t seem to matter. As a principal and founding partner of a consulting firm that eventually grew to 600 employees, I interviewed, hired, and worked alongside hundreds of business-school graduates, and the impression I formed of the M.B.A. experience was that it involved taking two years out of your life and going deeply into debt, all for the sake of learning how to keep a straight face while using phrases like “out-of-the-box thinking,” “win-win situation,” and “core competencies.”

via The Atlantic Online | June 2006 | The Management Myth | Matthew Stewart.

Excellent article. I didn’t expect the veer into philosophy there near the end but I enjoyed it. Good stuff.

Holding a model of the code in your head

This is something I’ve been thinking about recently – most of the bugs and problems I see caused by junior developers at my workplace are a simple result of not having a model of the software in their heads.

via Shaper_pmp comments on The history of UTF-8 as told by Rob Pike.

Not being able to hold my code in my head is one of the most frustrating parts of my work life. It’s how I like to work but it also causes problems when the model becomes so huge that it gets unwieldy and ugly.

Metrics

The new CEO at my work has directed the heads of all of the departments to institute metrics for measuring their departments. In a lot of the departments, that makes sense. Not so much in IT. We have one department for programmers, system/network admins, and computer support so finding metrics that would fit all of those was proving very difficult. As a programmer, I was against some of the ideas for tracking bugs as metrics outright. Our director asked for input and here’s the email I sent in preparation for the meeting we were going to have on the subject, slightly modified for blog posting.

I’m going to comment on the larger issue of metrics in general.

My general thought is it that measuring software development in this way is fraught with danger and unintended consequences. I know this is coming down from above so there’s not much that can be done but things like metrics and performance-based bonuses have to be approached carefully or they risk incentivizing the wrong things and/or disincentivizing the thing you were trying to improve in the first place.

First, here’s a great article from Joel Spolsky on a related topic, incentive pay: http://www.joelonsoftware.com/articles/fog0000000070.html While this isn’t strictly about metrics, it’s a great read and one of my favorite explanations for unforeseen problems with processes that seem like good things at first. It also goes a little into important things you’ll never be able to have metrics for.

This is a very thoughtful comment made by someone on Joel Spolsky’s discussion forum about research done into metrics. It puts things in a way I would put them so I’m just going to paste it in.

“My manager recently asked me to do some preliminary investigations re: the use of metrics. What I came up with (below) drew heavily on various threads discussing the topic here on JoS (which were the source of most of the supporting quotes):

1) Metrics are very difficult to do well.
- In the context of software engineering, “quality” and “productivity” are very hard to objectively quantify. In the words of Carnegie-Mellon’s SEI: “Unfortunately, most of the metrics defined have lacked one or both of two important characteristics: a sound conceptual, theoretical basis; and statistically significant experimental validation”

As one programmer put it, “… varying projects have wildly differing levels of difficulty. If my colleague spends two weeks writing a reusable, documented thread pooling class, and I spend two weeks dropping controls on forms, he may end up with 200 lines of code, and 5 bugs, I may end up with 2000 lines of code and no bugs. Really, he’s the hero and I’m average. But how will metrics explain this?”

2) Unless done well, metrics do more harm than good.
- Beware the ‘law of unintended consequences’ – accidentally creating incentives/disincentives for the wrong thing(s). Example: if checkins are used as a measure of productivity, incentive is created to check in more often (e.g. at the end of every workday) rather than when it makes sense to do so (e.g. when coding + unit test are complete).

“What ever you decide to measure is what you are going to get… And you’ll get NOTHING else. These sorts of extrinsic measurements (and rewards based thereon) cause you to be less focused on your work and more on the extrinsic measurements. You’ll be thinking “how many hours did I bill today” instead of “what button name is going to be clearest to the customer -resulting in fewer tech support calls, happier customers, and higher net revenue”.

3) Lines of code is not a reliable indicator of quality or productivity.
- Implicit assumption that more code = better, when in software often precisely the opposite is often true. Example: if lines of code are used to measure productivity, then there’s incentive to cut and paste duplicate blocks of code (the larger the better) instead of creating re-usable functions, so as to artificially inflate ‘output’.

“… the best programmer is generally the one who takes the most code away, not the one who adds the most code …”
“The best developers … spend the bulk of their time analyzing the problem, and a small portion cranking out compact, clean code.”
“… a one-line PERL program can be much harder to understand (and therefore more complex) than a 10 line one that does the same thing…”

4) Metrics should NEVER be used to rate individuals, e.g. for performance evaluations and/or to determine compensation
- Effort will be expended (often successfully) to “game” the system. Example: if developers are rewarded for fixing bugs, there is incentive to intentionally introduce bugs (even if presumably easy-to-repair ones) to increase opportunities to garner rewards. Alternatively, if number of reported bugs in a developer’s code is a factor in their appraisal, there is a strong DISincentive for QA to report bugs – either the bug tracking system will be bypassed, or bugs will simply go unreported.

Other examples are as cited in 2) and 3) above.

5) If correctly designed, aggregated metrics CAN be useful for measuring the productivity of a team. Collecting metrics for an entire project over time can mitigate some of the local variability that leads to the weaknesses described above. But they must be collected consistently over time until a meaningful body of history is accumulated, and even then the limitations of the metrics so gathered must be understood and acknowledged.”

I’m 100% behind trying to produce better quality work. I work hard on my own to improve my code and my processes. If the goal is to improve quality though, it’s much more complicated than just getting some numbers together and seeing if they go up or down in 6 months. Improving quality is a process, and a complicated one at that. One of the things my coworker and I spoke about when he was getting ideas for QA is the philosophy of owning quality for the whole process of development, not just testing. One part of that process could be using the various code complexity and static bug analysis tools on our code. We could use this information, over time, to help increase the quality of our work. But if we were to just implement these tools so someone could record the number of bugs and use that against us in a review, the incentive to utilize the tool to help overall quality would be reduced. I’m not sure what the answer is if we’re required to find some numbers to record and post. It’s a hard problem and one we for sure need to think hard about.

At our meeting we ended up choosing 3 metrics that everybody could live with and we dodged the bullet of trying to use our bug tracking system to produce metrics. That was my goal for the meeting so I’m happy with how it turned out. The programmers also decided that we were going to work on our own informal processes for improving quality and do our peer metrics to help with this, which will be great. I’ll talk more about this later as we work on it.

The War Room

A month or so ago one of our VPs moved up to what I call the high class end of the building, where all of the execs are. This left her very nicely sized office open and since we’d recently had to give up one of the conference rooms we’d been occupying for a year, we siezed the day and the office. We got a small projector and “liberated” a long table from our big conference room to make a War Room for the programmers to work together and try to knock out the last of the big problems on our project.

This has been hugely effective. We all have different skills and while we communicate fine normally, having everybody in the same room has taken our game to a whole other level. The other day we took the most dreaded task (adding a vaguely defined new line item into a statement that somebody else wrote) and 2 of the guys worked on the technical aspects of it while I dug into why we needed the line and what it really meant. By the time they had figured out the mechanics of adding the line, I had figured out the logic for what numbers to add up and we got it mostly done in that one day. We had a few smaller details to work out but those are done and so far our Product Owner loves it, and says the customers will love it as well.

I’m not sure we’d want to work like this all the time but having the War Room has certainly been an eye opener for us. We’d thought in the past it might be useful to sit with a projector and work together but hadn’t taken the opportunity. Now we know how valuable it is though and will be doing it again I’m sure. Unfortunately they’re about to fill the office with a new hire but until then, we’re camping out and taking care of business.

Normally our conference rooms have little calendar pages on them to tell you who has reserved the room. Since this one didn’t have one, I made this to tell people the room was occupied. I wanted it to be funny though to hopefully defuse any negativity people might have about not being able to use the room. We haven’t heard much grumbling so I think it succeeded.

My First Agile Project: Go-Live – The Final Frontier

Originally published on AgileSoftwareDevelopment.com

Picture courtesy of papalars. on flickr

We did it! The project I’ve been talking about all this time has finally gone live and is now being used in production. Pretty much everything worked fine on launch day as well, which was nice. In this installment of My First Agile Project, I’ll talk about the last week of the project and where we go from here.

The last weeks of any project are pretty hectic and this was no exception. Our last week was a weird one though as we were theoretically in a code freeze (more on that below), and we still had to finish final testing, and we had to be done by Thursday so our database admins could start the data conversion first thing Friday morning. We all pretty much ran around like chickens with our heads cut off all week but once Friday came a weird sense of calm had settled over most of us (it might have been a fog of fatigue or brain tiredness, it was hard to tell). The DBAs had run through the conversion process 29 previous times so while they were working, it wasn’t some new process. The conversion process ran like clockwork, even finishing a few hours earlier than projected, and on Sunday we began the final Go-Live steps.

More »

FizzBin!

We need a word that says “I know tech” when you’re on the phone with tech support, you’d just say “Fizzbin” and they’d know.

Scott Hanselman’s Computer Zen – FizzBin – The Technical Support Secret Handshake.

Yes, I fully support this idea. I hate having to call tech support and sit through the first 5 pages of the support script but I also feel like a jerk when I have to say “I ran an ISP for 5 years, I know what I’m doing”.

My First Agile Project: The Last Mile

Originally published on AgileSoftwareDevelopment.com

Welcome back to My First Agile Project. I spent a few weeks doing as little as possible but now that I’m back at work we’re starting to head toward the actual end of this project. For real this time; barring any natural disasters, stress-induced insanity, or alien invasions we should be live by the end of the month. So the next couple of posts in this series are going to be about the end of My First Agile Project as we complete this and transition to whatever comes next.

As I’ve discussed before, we’ve missed a couple of other deadlines in the past but this one just feels different. On past deadlines, when we thought we were close enough to done we’d find a 3-day weekend and try to decide if we could finish everything by then (converting all of our old data takes a long time so we have to basically shut the company down while we do it). Of course, things come up and we’re too optimistic so when it comes down to it we’ve had to abandon the previous dates. We thought we were going to be able to do it at the end of November but again we missed it due to changes being made at the last minute and unforeseen problems. This time though, our list of remaining issues is small enough that when we decided on this new date we were all a lot more comfortable with it than in the past. This feels like an actual date of completion for everything, not a deadline we’re rushing to meet.

More »