spencegreen.com |
Stuff |
spencegreen.com |
Stuff |
The key to efficient programmer tasking involves telling programmers exactly what to do and then allowing them the space to do it. Practically, this means providing them with specific development tasks in a sequential order. If the project’s tasking model can achieve these mischievously difficult conditions, then programmers can enter the ‘Flow’, which is impossible with heavy context-switching.
Below, I describe the task model used in my team’s software process. An iterative software project has three task types:
An effective tasking model has several key requirements:
Finally, each engineer should have a personalized view of his work assignments that is not cluttered by unrelated tasks. He can immediately determine not only the current day’s objective, but also his future workload.
Organization
All tasks should appear in centralized container that is collectively owned, ie all programmers have write permissions to it. Most web-based project management tools (FogBugz, Basecamp) and enterprise portal platforms (OpenText Livelink, Microsoft Sharepoint) can satisfy this requirement. Tasks are organized in the “To do List” using the following abstractions:
If your project management tool is integrated with both your requirements management system and you change management (CM) tool, then you can use the same organizer for IRs and CRs. Otherwise, you must create a separate tasking model in your CM package.
What to Do Next
Programmers should receive an email notification after a task is assigned to them. They must then provide estimates:
IMPORTANT: Programmers should not change task due dates if they encounter a delay! The tasking activity has little benefit unless programmers improve their personal estimation skills. When an engineer changes a task status to ‘Completed’, the task manager will record the differential between the estimated ‘Due Date’ and the ‘Completed Date’. Programmers should challenge themselves to minimize this interval.
A Daily Regime…
Programmers start their days with the following process:
IMPORTANT: The task list has no purpose unless it actually reflects what the programmers are doing during the day. THEY are the source of project status, for management without data is nothing more than sorcery. Good estimates build credibility, which the team should gather rapaciously.
Good user interface design is mischievously hard. “Simplicity” is the fad these days, thanks to Apple and indie software teams such as 37signals. But simplicity follows complexity, and wading through complexity requires separating vital things from everything else. Do you think that it’s easy to identify important ideas and fastidiously adhere to them? Stop smoking. Don’t lust. Call your mother daily. Don’t be mean. Simple doesn’t mean easy.
Here are several principles that have emerged from my reading over the last few weeks. Remember that methodologies only supply the raw material for good design: feature sets, response requirements, accessibility needs, etc. Making a design come together requires practice, taste, and a little luck.
If you could step into someone else’s shoes for a day, who would it be and why?
In an interview during the 1994 US Amateur Golf tournament, a reporter asked a giraffe-like, 19-year-old competitor who he most admired in the sport. “Me,” replied the young golfer.
“What?” said the incredulous writer.
“You see,” Tiger Woods explained, “every golfer has weaknesses. I take the best qualities from each player and add them to an ideal golfer. I aspire to play like him, and since he only exists in my head, I must respond ‘me’.”
As an avid reader of biographies and student of people’s lives, I too have developed an Ideal Man in my mind. He is at once many people and no one at all. I would like to be him, but only for a day. Let me describe him to you.
My Ideal lives a simple life predicated on a personal code. Like Andrea Bittel, he believes that liberation comes not from total freedom, but from “living within a set of limitations that we have prescribed for ourselves.” He agrees with the equanimous Victorian explorer Sir Richard Burton that, “He noblest lives and noblest dies / who makes and keeps his self-made laws.” He is frugal, acquiring things only in light of need. He keeps promises and is deceptively modest. He rises with the sun, works vigorously, and is obsessed with the quality of his labor. At the same time, he has a deep love of humanity. He greets the cashier at the gas station by name and gives his money sacrificially.
My Ideal believes in God. He knows that economy offers no solution to human suffering, and that money and hope have a false correlation. He has seen that dogmatic empiricism leads not to truth, but to arid, dehumanizing stoicism. For him, modernity is just another boring experiment with self-help, not an existential panacea. He is humble, because he knows that he is flawed.
My Ideal is a compulsive learner and producer. A quote from James hangs over his desk: “If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation.” He knows that time is the only real capital a man has, so he stewards his own with miserly care. He seeks vital knowledge, knowing that it will lead to vital output.
Finally, My Ideal is a fatalist. By understanding that his life’s work will be confined to the section of the library where students go to hide, he has liberated himself from the tyranny of the word ‘legacy.’ He does not waste minutes, because he knows that he has few of them. He has planned his own funeral well in advance, because inevitable things do not scare him.
Why would I be this person for a day? I believe that life is a constant struggle against imperfection. At times, it would be encouraging to know what heaven felt like.
A recent software presentation that I saw started with an “architectural discussion.” One slide listed “Object/component-based design” as a feature, which was qualified by the usual platitudes including “Maximizes software re-use.” The slide then made the bold leap to “faster development” as the principal benefit of this “design decision.” I sighed. Two decades after “re-use” entered the technical nomenclature, the term is still misapplied. Re-use remains a misunderstood ideal with more promise than payoff.
Parnas’s 1979 paper, “Designing Software for Ease of Extension and Contraction” responded to four common software objectives:
The common complaint against software here was that such ostensibly jejune objectives became intractable. Parnas began with the surprising description of programs as “abstract mathematical objects.” But mathematicians state and prove theorems, seeking generality. If a mathematician becomes aware of “a set of closely related theorems, he responds by proving a more general theorem.” A good theorem is invariant across instances. We would prefer a commutative property that applied to both addition and multiplication, for instance, over one that applied to only one or the other.
Programmers, on the other hand, respond to a minimal requirements set. Generality therefore has necessary design and construction costs, for that principal is de facto “not minimal” (A performance cost often exists, too). Further, programmers often associate generality with the absence of local invariants such as magic numbers and tight coupling. Real re-use has system-level implications, though.
Parnas suggests dogmatic use of a “uses” relationship between “components” during system specification. The “uses” relationship is of course the intellectual ancestor of composition, a tenet of OO design. Jacobsen defined composition in 1992 as structuring an object–which is a number of operations and a state–by its parts. A family, for example, could be composed of a man, woman, and child (more liberal compositions are of course possible). The “uses” relationship still exists in UML and frequently appears in object diagrams. Furthermore, “real” object-oriented languages such as Ada and Smalltalk make expression of this concept possible. Why then does re-use remain a novelty?
Two principal problems exist. Within a company, the cost of finding a general component is often high. Basic information management issues such as the absence of a centralized repository and poor internal search capabilities are obvious causes. This argument is unspecific, however. The real problem is an instance of the free-rider problem (this is especially true in contracting organizations). Projects are often unwilling to accept the costs associated with generality even in light of the utility realized by both that project and other company groups. “Re-use” therefore becomes a topic of much comment and little consequence. It costs too much.
Re-use works if it is the chief end. Four scenarios come to mind:
The OSS community has been the principal beneficiary of re-use’s promise. An OSS component must exist as an autonomous element on the Internet to gain support, therefore making generality and interoperability key considerations. The absence of formal funding also eliminates the free-riding phenomenon on the developer side.
Re-use has failed as a “silver bullet” in the software industry, and it will continue to do so.
Like many programmers, I have long considered interface design an artistic activity best reserved for aesthetes who cannot design sort functions. One of my working software theories has been, “Programmers don’t design interfaces. Interface designers design interfaces.” My recent foray into graphical design has caused me to revise this axiom: “Programmers can design interfaces if they study interface design.” This is where I found myself several weeks ago.
During the first week of my research, I petitioned my manager for access to “the User.” After all, “enlightened” interface design teams pity the user, right? Not always. I spent several days building prototype screens and realized that not only did I not understand the user, but also that the user did not understand himself. My current project is a new system that will require new processes, training procedures, and internal organizations. Staffing needs are uncertain. Roles are uncertain. Even the system’s features are fluid. Therefore, “the User” does not yet exist. It occured to me that “Usage-centered design” fails in such a scenario, as observed by Don Norman:
Think about that last point. A fundamental corollary to the principle of Human-Centered Design has always been that technology should adapt to people, not people to the technology. Is this really true?
Frustrated, I called a friend who currently studies design under Norman at Northwestern. As with most leaps into new technical fields, I found that the conventional knowledge was about a decade out of date (a revelation consistent with Steve McConnell’s assertion that software ideas take 10 years or more to percolate from academia to industry). “Activity-based” design is the new model. Activities are user objectives that consist of tasks, which are user actions. Discovering activities and tasks yields insight into the user’s ultimate goals. Good interfaces result from a comprehensive understanding of these goals.
Whether “activity-based” design will survive The Next Big Thing remains unclear. The approach has intuitive merits, for Norman rightly observes that useful tools like pens and musical instruments require educating the user. One can hardly imagine that Les Paul held user forums while developing the electric guitar (possible questionnaire: “Does this device help you shred more?”). At the same time, the concept of activities and tasks falls squarely into the faddish realm of process thinking characterized Enterprise Architecture, ERP systems, and BPM. But a processes are like algorithms, which have been studied for millenia. The salient insight is that most people don’t think in terms of algorithms, but most useful activities require them. With only a hint of elitism, I therefore suggest that interface designers first try to clearly state what needs to be done, approaching the user after the heavy intellectual lifting has been accomplished.
Interface Design Tools that I’m using now:
NickFinck wireframe stencils
UML2.0 stencils
Dimensioning stencils
The Gimp
Over the last several days, my project has gone through the Critical Design Review (CDR) process. Although the format differed from the CDR that I had organized in February, the presentation problems, organizational needs, and technical outcomes were similar. CDRs have become a staple in most engineering organizations, and government contractors in particular must hold them.
In my experience, most project teams scramble to meet the CDR deadline, often submitting work that is incomplete or unconsidered. This circumstance harms both the team and the customer. For example, our group tried to meet a program management quota of 30 slides per person. The “fluff” did not escape the customer’s notice, damaging the team’s credibility.
Instead, I suggest that CDR teams emphasize quality over quantity and use the CDR forum to educate the customer and capture requirements. Think of the CDR in as:
Below is a list of guidelines for maximizing the CDR’s benefits. Both project managers and engineers can use these suggestions, for a well-integrated team blurs the distinction between these two roles.
Planning and Preparation
Execution
Post-Op
A CDR comes from the “Waterfallish” world, but it works well at the beginning of an Agile project as well. Although design work may be performed during Agile/XP iterations, architecture must necessarily come first. A raw feature set must also be developed to allocate builds and iterations. These work artifacts are obvious candidates for a CDR.
An unattributed byline about Kurt Cobain in a recent GQ issue caught my attention for its terse description of a complex person.
A man of chronic contradictions, Kurt Cobain exuded an energy that was both savage and artistic. When Nirvana readied to play Saturday Night Live on January 11, 1992, Nevermind had reached Billboard’s number one spot, and the music world waited to meet its new 24-year-old star. He wore a Flipper T-shirt under a mold-colored cardigan and hair he’d dyed the night before with strawberry Kool-Aid. He also blew the shit out of the room with a 1965 Fender Jaguar the color of a Doberman and introduced us to a new status quo for cultural icons. Glamorous, dirty, quiet, and loud—Cobain would be dead in two years. And we’re still trying to figure him out.
The selective use of adjectives makes this article work: “savage”, “mold-colored”, “glamorous, dirty, quiet, and loud.” This is Seattle, and the apathetic movement that it spawned. Using an expletive makes the writer vulnerable to the reader’s contempt, but in this case, it seems to resonate against the grinding hum of the brown Fender. Here, the writer has sketched a book-length subject in 114 words.
Here’s the SNL performance.
Here are two coding tips that I have found useful in recent days:
Explanatory text in a textbox can force the user to read directions. The textbox could say something like, “Enter search terms here separated by commas.” But when the user places the cursor inside the textbox, the instructions should clear. The standard ASP.NET textbox control does not have an OnFocus event, but the same effect may be achieved with JavaScript. Add an attribute to the textbox control during the Page_Load event:
//Note that value is set to an empty string (two single quotes)
if(!Postback)
{
txtBox.Attributes.Add("onFocus","this.value='';");
}
Some ASP.NET controls use JScript Eval statements for databinding. In some cases, you may want to include single and double quotes in the Eval format string. Use HTML escape sequences in place of quotes:
Consider the following example, which uses an Eval format string:
< %# Eval("Url","this.window.href='{0}'") %>
Powered by WordPress
Entries and comments feeds.
Valid XHTML and CSS.