A Proposed Project
Our esteemed interlocutors on the lists sometimes feel that our answers are glib or simplistic. They suspect, for example, that the fact that we use very few Mock Objects is due to working on simple problems. Our claim is that we don’t work on complex code, and that’s because we write simple code even for tricky problems. Doubtless the answer is somewhere in between. Last Monday Chet Hendrickson and I were chatting about a potentially interesting problem, which might keep us engaged long enough to have some fun and write about some ideas.
Usually these articles are very chronological, reporting things as they happen. Here at the beginning, we’re going to break that rule, to give you an opportunity. I’ll explain as we go along.
Chet and I met for lunch Monday, for just an hour. We talked about two things, my local problems and a software application he had in mind. We probably split the time, because when I get to kvetching I’m hard to stop, but anyway, what we’ll talk about here in the first couple of articles is the result of somewhere between 15 minutes and an hour of work. Probably 30 minutes. The time is potentially important.
The basic idea is to write a program to analyze a shotgun’s shot pattern. Chet is a trap shooter, and a darn good one, and one of the things you do is blast a sheet of paper from 35 yards and look at the pattern to see what it tells you about the gun and yourself. I gather that what you want is a fairly symmetrical pattern, more dense in the middle than at the edges, probably centered a bit above the point of aim.
Our product is a computer-based service. People shoot holes in paper, ship us the paper, and we produce a computerized report telling them all kinds of important things about their gun and their shooting. We imagine that they’ll get a multi-page printed report, some of which will be boilerplate, some perhaps boilerplate with selections and substitutions based on the analysis, and a page or two of nifty graphs showing and analyzing the pattern.
Story ideas include:
- Digitize a photo of the shot pattern, identify all the holes.
- Compute the center of mass of the holes.
- Display info about shot density in various areas of the target, center of mass, perhaps identify inappropriate clusters.
- Display cool and obviously expensive graphical results in color and gray scale, justifying the incredible cost of the resulting commercial product.
- Include pictures of what a probable break would look like if hit by shot in each of the various areas. (A central hit destroys the target, edge hits crack it in a couple of pieces, and an expert can tell from the break what part of his pattern hit it.)
We figure the main report consists of perhaps 9-18 graphs and little paragraphs, arranged in a 3x3 table perhaps. The report should be in PDF format, we think, though there might be a web form as well. For now, we’re thinking it’s a mail-order service with a formatted, nicely packaged report.
Blue-skying about the product, with just the ideas given here, in the roughly half-hour we had, we did some estimation for the project. In the next article, we’ll say what we can about our estimates. Here, we’d like to challenge you to estimate the project, noting your assumptions and results. If you’d care to write us about it, please do. In any case, give some thought to the size of this project and how much (or how little) estimation you can do.
Often, faced with some project, people are concerned that they’ll have to have all the stories, dig deeply into the design or other considerations, go through lots of rigmarole to decide how big the project is. We really don’t agree with that, as we’ll discuss as this project goes on. For now … you have your mission: estimate this project.
Please write us (ronjeffries at acm dot org, chet at hendricksonxp dot com, subject [ron] Simple Design) and tell us what your estimates are, what you need to know that you don’t know, and so on. And write to us as the series goes on, with discoveries and questions.
Thanks! This is going to be fun!