May 29th, 2014 |
The Register: Fat-fingered admin downs entire Joyent data center
As for the fat-fingered administrator? “The operator that made the error is mortified, there is nothing we could do or say for that operator that is going to make it any worse, frankly,” Cantrill said.
Nor would Joyent want to, he explained. The goal for the company is to learn from the problem and get better, not mete out punishment. “You don’t teach dolphins with a shock collar,” Cantrill explained.
This used to be the attitude throughout the University, and still seems to apply here in ITS-Systems. From what I’ve heard, though, there are places where “meting out punishment” seems to be the rule now.
May 2nd, 2014 |
April 7th, 2014 |
Today is the 50th anniversary of the announcement of the IBM System/360. Some coverage here and here.
February 11th, 2014 |
Interesting: Context Reports
This morning I realized I might have a productive way to twist status reports into a useful exercise. Let’s call them context reports. A status report documents actions both completed and planned. A context report documents the reason why (and to a lesser extent how) you’re completing these actions and I suspect this information is far more useful to everyone involved. Let’s try it out by transforming common status report items into context report bullets.
February 10th, 2014 |
I found this from a link from the Typical Programmer: People and methodologies in software development. The abstract:
This thesis reports on research performed over a ten-year period, interviewing project teams, participating directly on projects, and reviewing proposals and case studies. The research addressed three questions relating to people and software development methodologies (Q1 through Q3), and produced six results (R1 through R6).
- Do we need yet another software development methodology, or can we expect a convergence and reduction at some point in time?
- If convergence, what must be the characteristics of the converged methodology? If no convergence, how can project teams deal with the growing number of methodologies?
- How does the methodology relate to the people on the project?
The answers are:
- A methodology is a formula describing conventions of interaction between roles.
- People’s characteristics, which vary from person to person and even from moment to moment, form a first-order driver of the team’s behavior and results. Such issues as how well they get along with each other and the fit (or misfit) of their personal characteristics with their job roles create significant, project-specific constraints on the methodology. This result indicates that people’s personal characteristics place a limit on the effect of methodologies in general.
- Every project needs a slightly different methodology, based on those people characteristics, the project’s specific priorities, and the technologies being used. This result indicates that a team’s methodology should be personalized to the team during the project and may even change during the project.
- A set of principles were found that can be used to shape an effective methodology to the above constraints. These principles deal with the amount of coordination and verification required in the project, the trade-off between rework and serialization of work, and the trade-off between tacit and externalized knowledge in use by the team.
- A technique was found to create a situationally specific methodology during the project and in time to serve the project, and to evolve it as the project progresses.
- All the above suggests a repeating cycle of behavior to use on projects.
- The members establish conventions for their interactions — a base methodology — at the start of the project. This can be likened to them “programming” themselves.
- They then perform their jobs in the normal scurry of project life, often getting too caught up to reflect on how they are doing.
- They schedule regular periods of reflection in which they reconsider and adjust their working conventions.
These results have been used successfully on several industrial projects having the usual time and cost pressures on the staff.
I think this is exactly right. I’ve had an idea for a post about humans in software development floating in my head for a while; maybe I’ll get to it soon.
January 22nd, 2014 |
An editorial in Monday’s Daily Texan ended:
… UT should hire UT staff and Texas programmers to custom build its administrative systems.
I’m not sure why the author would suggest that. After all, that’s what the University’s been doing for almost five decades, and look at all the pain and suffering that’s caused.
There are other reasons you can tell this wouldn’t work:
- You never see articles in magazines for CIOs and CFOs that talk about custom building, so it must be a bad idea.
- It would require business managers at the University to have a passing acquaintance with information technology and technology trends. They might even need to develop a vision about how technology could help the University work better.
- Have you ever tried managing programmers? It’s the proverbial herding cats experience. It’s much easier to pay other people to deal with that.
- If something goes wrong, you can’t blame it on anyone else.
We definitely need to nip this idea in the bud.
December 20th, 2013 |
If your web application requires that my browser support Flash or Java, it’s broken, and you should fix it.
December 10th, 2013 |
If printing copies of your slides and handing them out helps your audience, you did your slides wrong.
October 16th, 2013 |
This is pretty good: How to develop unmaintainable software. In fact, I recommend the whole blog.
May 28th, 2013 |
John Gruber highlighted this on Daring Fireball, and I think it’s worth repeating. From an interview with Eric Catmull, president of Pixar:
On managers self-destructive tendencies for creative work:
The notion that you’re trying to control the process and prevent error screws things up. We all know the saying it’s better to ask for forgiveness than permission. And everyone knows that, but I Think there is a corollary: if everyone is trying to prevent error, it screws things up. It’s better to fix problems than to prevent them. And the natural tendency for managers is to try and prevent error and over plan things.
Yes, the only way to avoid making mistakes is to not do anything, but that’s a mistake in itself. When management has no tolerance for bad things happening, nothing good will happen either.