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.
April 12th, 2013 |
A link to this video came over the IBM-MAIN mailing list this morning. It’s a training video produced by AT&T in 1973 on the computer services available at a Bell Labs facility. Enjoy!
March 1st, 2013 |
The Web Standards Project (WaSP): Our Work Here Is Done.
Yes, web standards are much more closely followed today than they were in 1998. Great work! Also, in a world where organizations often seem to acquire a life of their own and continue long after their purpose has been achieved or become moot, it’s great to see one declare victory and disband.
February 18th, 2013 |
Uncategorized | 2 Comments
This is from an email sent to the IBM-MAIN mailing list by John Gilmore:
G. H. Hardy wrote that 1) intellectual curiosity, a desire to know how
things work, 2) craftsmanship, the need to do the best job one knows
how to do, and 3) a desire for recognition, even fame, are sine quibus
non for success at any intellectual task.
Managers who employ programmers who lack these three characteristics
get the mediocrity they deserve.
It is hard to resist the conclusion that these managers, who are not
themselves programmers, have, with no understanding of the ‘skill set’
that programmers need, taken refuge yet again in crackpot realism.
Production lines, particularly those that are highly automated, can be
managed. Programming projects must be led.