A colleague wrote the following note to me today:
I am trying to fathom what you have against an additional library into the architecture. The AJAX framework provided by MS$ is an additional library we have to use, there are Oracle libraries we have to use…what is the roadblock you have with an IronRuby, IronPython, or Lua library? Limiting the number of libraries, selective in the process is essential, but if to restrictive, can ignore industry standard flexibility in our system.
My reply follows:
I’m not limiting the inclusion of other libraries. I prefer to think about the problem first, then select the best method of expression. Language is simply that: a method of expression. It is almost always better to program in the language–namely, through the use of native syntax–than to program through it. The latter mode is a common mistake: have you ever seen someone write Java as if it were C?
An ad hoc approach is the alternative. In this case, we choose technologies first and solve problems later. This technique is used often in OSS. Here you must recall the essential difference between commercial software development and experimentation. Read this post.
We don’t exercise all of those steps here because we don’t do proper software development. The lesson, however, is this: the decisions that you make as a coder have lifecycle costs associated with them. Think about it: you include library X. We have to learn that technology. I&T has to test it. CM has to integrate it into the nightly builds. Maintenance has to update it, changing custom code as necessary. A whole succession of maintenance programmers for the next 5-10 years must follow this process.
You must also consider the risk of the technology disappearing during the software’s lifecycle. This is always a risk in software, but it can be approached intelligently. Microsoft has made a significant capital investment in .NET, and they have included AJAX in .NET 3.5. Moreover, other companies have staked their viability on .NET (incidentally, this is the anti-trust argument against Windows in the enterprise space: companies cannot afford to move away from it). Can you say the same for other technologies? Perl was the “next” silver bullet in 1995, but we are still waiting on Perl 6. In the meantime, it has been superseded by faster bullets: Python, Ruby, and Scheme.
I recommend that you read the book Beyond Software Architecture by Hohmann. Technology decisions cannot be made in isolation because they impact the business. The converse is also true. We must always be thinking not only in terms of “wow, this is cool”, but also in light of the question: “Does this make good, long-term business sense?”
I’m not trying to limit your creative freedom. I am trying to show you that we must make considered decisions at this point in the “cone of uncertainty.”
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:
- Non-technical: Any task not associated with code. Includes most work completed during the Preparation phase. Design schematics, system-level use cases, and whitepapers are all non-technical tasks.
- Implementation Request (IR): Directly associated with both a Level2 software requirement and the code that implements the requirement.
- Change Request (CR): Directly associated with a change to an existing requirement and the code that implements that change.
An effective tasking model has several key requirements:
- Unambiguously answers “What”: The task data object should include a title, detailed work instructions, and links to relevant documentation.
- Enables Easy Estimate Tracking: An engineer must be able to enter labor estimates AND evaluate his performance.
- Associates Tasks with Exit Criteria: Each task should be associated with a reviewable work product.
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:
- Tasks: Each of which is associated with a task group.
- Task Groups: A collection of tasks associated with a milestone.
- Milestones: Date upon which a specific business objective must be accomplished. A milestone frequently coincides with a Work Product Inspection (WPI).
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:
- Set due dates for each milestones.
- Set due dates and durations for each of your tasks relative to the associated milestones.
- Add any missing tasks
- Provide work 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:
- Review current task assignments.
- Set a task’s status to ‘In Process’ when starting work; change the status to ‘Completed’ after finishing the task.
- Add new tasks as necessary.
- Arrive at the morning ‘Stand-up’ meeting aware of not only your current work assignments, but also the team’s current location in the project trajectory.
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.
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:
- A pre-validation meeting: Demonstrate analytically the design’s compatibility with the current requirements set. Eventually, the customer will validate the code against the requirements. Show him that you have integrated all of his needs into your current design.
- A training exercise: Have you ever listened to a fellow developer describe a complicated algorithm or component? That guy is working on your system, but you don’t easily understand his approach because you aren’t familiar with his area of the code. Now think of the customer. He must digest the entire design with NO experience in any part of the system. Use the CDR to train the educate the customer, not overwhelm him. Other members of the engineering team will benefit as well, for their awareness of the system will increase.
- A requirements capture meeting: Each presenter should identify a list of design issues and requirements questions prior to the presentation. During a CDR, you have the customer’s undivided attention. Instead of lecturing him, ask him questions and make him think.
- A technical design forum: The team’s engineers should attend every CDR brief. Require them to take notes and submit evaluations. A CDR exists within the same genre as the Fagan inspection and the requirements review. Treat it with the same formality.
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
- Don’t use a boilerplate checklist: A CDR’s main objectives are gathering and disseminating information. Circumstances dictate the best methods for achieving those ends. This is not brain surgery. Develop a considered approach based on the project, avoiding “Big M” methodologies.
- Emphasize quality over quantity: Don’t use slide quotas. Treat slides like money and spend them wisely.
- Use the 4-6 rule: Each slide should have between 4-6 bullets, and each bullet should have between 4-6 words. If a slide requires elaboration, talk through the slide using a whiteboard or create a handout for the audience.
- Print the Presentation: Every participant should have a bound copy of the presentation. In this way, you may include complex drawings and figures that may be difficult to read on the projector.
- Plan an internal CDR (iCDR) or “dress rehearsal”: The team should go through the entire CDR sequence together at least a week prior to the real conference. The presenters should speak as if giving the real presentation and the audience should not interrupt the talk unnecessarily. The latter observation brings us to…
- Identify a moderator: CDRs inevitably stall under the weight of digressions. Identify a moderator keep the meeting moving.
- Identify a scribe: It is too difficult to compile a piebald stack of scribbled notes after the meeting. Identify a scribe, give him a laptop, and require him to enter observations formally into Telelogic DOORS or an equivalent tool. Important comments and decisions are often lost immediately after a discussion takes place. Instead, capture all of the comments (annotating them by speaker and slide number) and present them as a “Minutes of Meeting” document to the customer.
- Assign a Master Reviewer: Select a technical leader with broad system knowledge to review all of the slides prior to the iCDR. The reviewer should eliminate redundancies, identify major themes, and resolve formatting inconsistences. The body of slides should reflect a coherent picture of the system. A single mind can evaluate the team’s work with respect to this objective.
- Detail = Credibility: Everyone knows that block diagrams, state charts, and data schemas require time and effort to develop. Include them in the presentation. Together, they show that the team is operating at a satisfactory level of precision.
- Think about Food: Don’t order the usual corporate garbage: donuts and coffee for breakfast, sandwiches and chips for lunch, Coke in the afternoon. Set the tone for the day with food. Start the day with fresh fruit, toast and French jam, fresh juices, and smoked salmon. Stimulate the body with healthy food, then stimulate the mind with a careful presentation. Impress the customer.
Execution
- Choose good communicators: No leaning on furniture. No staring at the projector screen. Use vocal inflection. Discard nervous habits. Dress well. A CDR is not a political rally, but it is also not Thursday night at the pub.
- Use amphitheater-style seating: Ensure that audience members can talk to each other. “Lecture room” seating prohibits discussion.
- Ban Blackberries: Place a box at the door and force people to dump their weapons into it. This is a serious discussion that requires undivided attention. Distractions caused by Joe Flowingut and his HIGH PRIORITY ISSUES!!! cannot be tolerated.
- Use two projectors: Display diagrams on one projector and talking points on the other.
Post-Op
- Debrief: Hold an engineering meeting immediately after the CDR. Sluggishness usually occurs after such an ordeal. The PM should develop a near-term list of action items and assign them after the last slide is presented. Don’t wait for the final analysis before you start moving forward.
- Requirements changes: Identify them, analyze them, and present them to the customer.
- Design changes: Get the engineers working on these immediately. Impact analysis should be the first step.
- Risk assessment: Develop a risk list and use it to re-evaluate the project schedule.
- Action items: Develop a list of action items for the customer. What do you need from him? What issues must he address? Set a date for follow-up and get your questions answered while the issues still occupy his mind.
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.
