DESH: Dying is Easy, Software is Hard (with my apologies to Comedians) by N.D. Pearson
These are concepts and notes that may turn into a book someday.

Creativity helps
Basic writing skills help
If this sounds like writing, it is. Software design is like writing a book.
It needs an Architecture (storyline) and should be modular (chapters and paragraphs). And like most good stories, it should have only one Designer (author) or a very tightly knit group of collaborators.

Know what you are trying to do before you try to do it. Do not try to figure it out later or you'll soon find out why the last 10% of code can take 90% of the total time effort to write. And since 90% of the time budget has already been spent, know the rest of the story.
When in doubt, experiment.

You have a little project to design and code up a microprocessor sensor interface.
You whip out your UML tool and Model Design books and ... realize this thing is too small to have an OS. In fact, it may not even have a 'C' compiler.
So? .... You just head back to basics: Data movement and CPU operations.
The job is to move data from the sensor digitizing circuit (internal or external) to the output interface (parallel or serial stream) and maybe do some data processing on the data elements. If it's also controllable, then add a user interface (buttons, IR, serial port, etc.).
CPUs really only do a few basic things. Move data into the CPU, perform operations on data, move data out of the CPU, and do conditional testing for program flow control.
Interrupts can be viewed as hardware driven tests that can alter program flow.

Lazy programmers spend an extra 5% of their time documenting their code.
Inexperienced programmers don't document their code and enjoy spending 50% of their time trying to figure out what they did, why they did it, and what lead them to do it before they can start to work on why it doesn't work.
Lazy programmers end up doing less work.

Why Software Take Longer
Unless you've done this type of project several times before, 50% of your ideas will be wrong, 50% of what you do you will change, 50% of what you need to do you won't think of until you need it, and 50% of your time will be spent on other activities.
No wonder developing new software take 200% longer to do than expected!
NOTE: This also applies to the usefulness of Peer Reviews. Reviewers will find general coding errors, any functional error detection will be driven by what they think the code should do.

The value of your work is in its ability to be used by others. (somebody has probably said this before)

Good software works because it passed testing. Great software works by design.

Training needs to be provided that covers the processes and tools use by the project.
This would include the document control system, code version control, the compiler tool suite, meeting protocols, communications standards, etc.
For projects that acquire 1 or 2 people at a time, briefing sheets should be generated and a trainer assigned to brief the new team members.
For 3 or more people, a training session should be scheduled to present the information.
A training session should also be conducted as a review for all team members once a year. The session could cover all areas at once since it is a review.

Note Taking during debug
Use WordPad or other such light weight editor to record your trials and tests. You can cut-n-paste settings to it to easily repeat prior tests and configurations.
Use one file per day, per week, or per problem and include the date in the filename.
Example:DB_conIO_080319.ccon I/O debug for Mar 19, 2008
If you try something and then remove it, don't delete the entry. Use strikeout instead. This preserves your thoughts while you were debugging and can be reviewed later for analysis.
Put ?? in front of a line commenting a test or change note.
Put a ## in front of a line to record a result.
?? Change process order to scan block for zeros before processing
## minor timing improvement (2.6 us)

When you encounter or develop a new code process, try it out before designing it in.
Say it's a message handling protocol. Write a bit of test code to use it to pass messages between two or more code modules. This gives better insight into its capabilities and limitations. It may also produce other ideas about how best to apply it to the design and may even reveal new uses for the protocol.

Development Environment
The stability of the development environment is the most important concern of a software manager. Its configuration and setup should be tightly controlled and well documented. Setting up paths and environment variables can be tricky and complex sometimes and once done, the process and decisions made at the time can be easily forgotten or leave with the person that did the setup.
Paths to libraries and include files should be readily available to programmers.

When assigning a task, provide an estimate of hours, days, etc, that you think the effort will take. Then multiply by 3 to get the earliest possible time, date it could be completed by assuming that the recipient has no other tasks.
Most work estimates are bad guesses, but the more you make, the better you'll get. After awhile, you may only have to multiply by 2.

A manager should be able to describe, for each of their workers, what primary tasks should be completed for the week and for the month.

A manager should be able to estimate how much time is needed each day to be spent on answering e-mails and establish a time limit trigger to raise an alarm if this time starts to get excessive. This concept can also be extended to weeks and months to help manage time spent in meetings, presentations, vendor demos, etc.

The Manager as a Choreographer
When a manager has a vision and insight as to how their group fits into the overall organization, they should be able to describe the average day of their any of their subordinates. This is especially helpful to new hires in that it helps them organize their day and set up daily routines that help them get in sync with the rest of the team.
The manager should also insure a degree of interaction between team members. Even though each person may be assigned specific task, these tasks are rarely totally independent. Therefore, some minimum amount of daily or weekly interaction is useful to maintain a cohesive effort that moves the project forward and minimizes road blocks and surprises. (It also gives the team a better chance to meet milestones, gates, and checkpoints.)
Another analogy is that of a Conductor. The 'music' of the code should be harmonious, not a cacophony, blending of efforts by all of the team.

Does your project have well defined deliverables?
Do you know what this weeks goals are for each of your subordinates?
Do you know what the major risks are to your project and what your mitigation strategy is for each of them?

How do you give the few experienced programmer you have a way to oversee the design efforts of the less experienced programmer? Use the 1 day, 1 week process.
After giving a design assignment, meet in 1 day and have the designer give a 30 minute talk on their approach, their concerns, identified risks, and other basic design thoughts.
If they show an understanding of the problem, then meet in 1 week to see a development plan and estimate. If not, spend an hour showing them what they should have done, then meet in 1 week.
If the plan is acceptable, let them proceed, otherwise assign someone else or spend a day in training showing them what they should have done and how they should have done it.

Requirements are used to tell someone else about your design and to let them fill in the method of implementation.

Getting New Team Members Up to Speed
Any program, larger than a few people, should have an UNCLASSIFIED briefing for new team members. This briefing would describe the overall system and the area that the new team member will be involved in or responsible for. The CLASSIFIED sections can be presented as 'black boxes' and discussed from an interface or basic processes level. This briefing should also be reviewed monthly by a systems engineer to keep it up to date as the program evolves.

Time Management
Normal week:
Friday should be a clean-up and reflect day. Do documentation that's been put off, clean up code, plan the next week's activities, etc. If everything is humming along, crank out a bunch of small code functions or modules to help fill in the status sheets.
Crunch week:
Friday is used to prep for the weekend. Set goals and coordinate resource needs to minimize wasted time.

Management Warning Flag
Unless the project is a purely research or exploratory effort into new technology, major work efforts that seem to pop up out of thin air tends to signal that the design has not been well thought out. If this happens enough times, the project team can generate a feeling that the design leadership does not know what it's doing and that work estimates have no valid basis.
If this feeling sets in, then work efficiency and enthusiasm will diminish. The only remedy sometimes is to replace the design lead.

The goal of estimation is to make an educated guess of how much work needs to be done. Once a rational estimate of work is available, THEN a schedule can be generated based on resources that will be applied to the work effort.
These are two DISTINCT and SEPERATE tasks. They are mixed together only at the peril of the mixer.
An important part of the estimation process is the documentation of the justification for each component of the estimation. Any adjustment to the final estimation has to be weighed against the justifications used for the estimate and reflected in the changes to those justifications. The justifications are the basis of the estimate and are the difference between a random guess and a rational estimate.

Whenever possible, try to work in a team. Discuss what you've done and how you did it within your team.
Learn from their methods and have them critique yours. No one knows the best way to do everything and anyone can make a mistake.
Peer review is a fast track to better programming.

Team Leaders
It has been stated in books on project management (need ref) that a good team with a poor leader will do poor work and a poor team with a good leader can do acceptable work. Teams usually rise or fall to the level of their leader.

SCRs, SCCBs, and CM oh my
These have to be the scariest acronyms for software people. The main problem is that they usually get rolled up into processes that try to do all of them and everything else at once. There are three distinct concepts here. They are Change Control, Change Management, and Configuration Control and based on what phase the project is in, they have different goals.

Change Control
During Design Phase, change is an ongoing process. The job of the coder is to keep changing the code until it meets the description of the design. The job of the designer is to keep changing the design until it meets the intent of the requirements. This process is ongoing because no design is 100% complete or 100% perfect until the product has been retired and is no longer in use, and sometimes not even then.

Change Management
Change Management varies in its focus during the project. In the Design and Coding Phases, where change is rampant, the focus is on monitoring the amount of change activity going on and characterizing the changes. Unless things are really chaotic, not much is done to restrict change. However, after these phases, changes in design or code can have a more serious cascading effect on the project. Here, the manager needs to carefully manage change and assess its impacts before allowing change to occur. This is the primary realm of the Software Change Request (SCR) and the Software Change Control Board (SCCB). These are formalized processes that are needed to control change and to minimize potential adverse impacts to the rest of the project.

Configuration Management
One of the major complications of Configuration Management (CM) it that people lump Change Control and Change Management into it. The proper view of CM is that it does not matter how the changes came about, but that the snapshot-in-time or revision can be replicated as needed. CM should focus on Snapshots in time, Repeatable code builds, and Version control.

Design By Vision
Assume the system is complete and running as expected. Now, start describing how to interface to it and how it accomplished each of its tasks. Continue describing, in detail, what each module does until you get to a list of suggested or required functions that would be needed. No fair having a box that says "And then a miracle happens!".

Example questions to be answered:

Designing a Library
It's a good idea to have one file per function in a library. This will minimize the memory impact for each function. If more than one function is in a source file, the object file will be much larger than it needs to be. It also makes maintenance and re-verification, when changes are made, easier.
Not as important for desktop applications, but can be a life saver for memory constrained embedded ones.

The Friday Review Lottery
Everyone is given a chance to display work product(s) they completed that week. This can be a lunch activity. The workproduct can be code, a document, or what-ever.
Three minute maximum presentation.
Everyone secretly votes for the person's effort, not the person. No voting for yourself. Have fill-in ballots available.

-1 Needs work or not really up to standards (this is an optional score)
 0 Expected level of effort
 1 Good effort
 2 Excellent effort
 3 Wow. That's really neat. I can use that or it will help in what I do.

Tally the votes and rank the presenters.
Put 10 (adjustable) tickets in a bag with one ticket marked HALF-DAY FRIDAY or ONE-HOUR OFF TODAY or other similar prize.
The highest ranked person gets first draw. If not a winner, replace the ticket. The next ranked person then draws and replace if not a winner. Repeat for the top 50% of the participants (round up if odd number).
This allows people to present their efforts and shares knowledge between groups. It can also include admin and other areas, not just developers.
It can be a half-hour lunch time (10 presenters) or longer.
It is meant for small teams, but could be applied to small groups of teams, or used at monthly tag ups. Obviously, times, scoring, criteria, and prizes are all adjustable.

The Confidence Survey
What's the probability that the project will finish on time? or work at all? An anonymous survey of all of the project staff might help.

The Power of the Software Project Manager (SPM)
If processes are to be enforced to improve productivity, the SPM must have the power to cancel a project if it gets out of control. Without this power, which is needed if the SPM is given the responsibility for the company's investment in the project, the SPM has essentially no control over designers and developers that may have stronger personalities, more seniority, or greater company influence.
If the SPM is relegated to a position of bookkeeper and progress tracker, then the well documented and presented spreadsheets will be a fitting legacy to missed deadlines, cost over runs, and the evidence to support the lowest ranking of CMM, CMMI, EVMS, or any other level of process.

Iterative Development or Spiral Development Lifecycles
Using the design, code, test, add new feature, repeat does not mean that you can just throw a design together on a best guess of the day, hack it together, try to get it to work, then throw more stuff in and repeat.
Iterative and Spiral development methods are formal types of prototyping used for risk mitigation. They require careful thought in the design phase of each cycle as to what the most critical risk areas are and what code is needed to mitigate those risks in the most effective manner. Effective is the operative word here. It can mean fast development to answer an interface risk, testing a design concept for robustness against failure due to unconstrained data inputs, getting early feedback from the customer on a proposed GUI design, or any number of risk reduction methods. If used to get a product out the door with a minimum set of functionality, then they are more like the Agile process, but that too is a formal process that follows well defined methods and required activity.
The bottom line here is that all valid processes require careful upfront thought of the design and planning of the work effort to be efficient and effective. Always think through the entire lifecycle of the work product and not just the grand idea of the day.

E Pluribus Unum "Out of Many One"
One of the most important tasks of a design lead is to decide on the overall architecture or design philosophy to be used for a project. Studies have shown time and again that the best solutions to complex problems come from groups rather than from an individual. Since the group is made up of individuals, the design lead's problem is to extract the best parts from all of the individual ideas and combine them into a stronger overall solution. The operative word here is "extract". Care must be given to not filter the ideas. Few ideas are ever bad, they can however be inappropriate or non-applicable. The assumption is that the person offering the idea thinks that it is applicable to the solution being sought. Ideas are based on assumptions and if the idea is invalid, a look at what assumptions were made can be much more helpful than just rejecting the idea outright.
A job applicant once remarked that one of his unique skills was the ability to extract a strong good idea out of many weak ones. Not a bad skill to have.

The Need to Code before the Design is Completed
Assuming a Top-Down approach, design until you get the feeling that what you have may not work as expected, then implement what you've got to verify the design, up to this point, and validate assumptions made. It also gives you a better "feel" for how the system will work. This point usually occurs when the design is becoming so detailed that your pseudo code is starting to look like the language the project is to be written in. Other indicators of reaching this point are the need for hardware drivers to get real timing data, user interfaces or GUIs for user feedback on "look and feel", network interfaces and protocols to check data flow, etc. It can also be a good basis for verifying the tool chain to be used.
The one other thing that drives this point is that many designers used to be programmers and would like to take a break from the mental effort of design to the more mechanical effort of coding (assuming a good design document). This also gets back to getting a "feel" for how the design will come together and helps clarify the designer's vision of the final product.

Shalls come from requirements, wills come from design decisions
Shalls are normally based on Customer requirements, but can also come from business decisions, system design decisions, and other higher level project needs.
Wills are used to lock down architect and design tradeoff decisions. These need more "pedigree" support than 'shall' based requirements.
If the product is viewed as a collection of black boxes, requirements can easily take on a layered aspect. The requirements at a specific layer only relate to what happens outside the box that they as applied to and how the box will respond to input and possibly the formats of the data that move in and out of it.
If the overall architect requires something specific about how the box works, then this should be described in detail, with justification, in a concept or theory of operation document that is referenced by the requirement.

Approach, Design, Implement
Discuss with others the Approach that will be taken to develop a Design or for complex projects, an Architecture.
Once approved, discuss with others the Design that, if implemented, would meet the Requirements.
After the Design has been approved, discuss with others the implementation that has been done to fulfill the Design.
Each of these can also have an Approach, Design, and Implementation series within them. The discussions held within these phases can range from informal meetings to full blown presentations. The point is to have some form of discussion with others, preferably stakeholders, throughout the life of the project to keep focused on the goal of the project and to uncover, sooner rather than later, issues related to that goal.

Herding Kittens or Orchestrating the Design
In more than a few projects, the Software Project Manager (SPM) ends up trying to guide a number of seemingly independent entities that are supposed to be working towards a common goal. A common thread that arises in post-mortem analysis is that the SPM assumed that their Technical Leads and people assigned to them knew what they were supposed to be doing. Yet, in digging deeper, few instances could be found where the SPM was verifying this assumption.
There are various items to help orchestrate a project. The Software Development Plan (SDP) is a key document that everyone on the project should be familiar with in that it has the overall schedule, resources, and methods being used. Work Instructions should be the first place people go to for answers of what process to follow to do something.
Does everyone on the project know where these documents are and what they contain?
Good architect and system level design documents help focus design groups to play well together in that they are the basis for discussing interfaces and data flow between modules in the system.
Are interfaces designed first and are they well documented before the core processes are developed?
A well thought out design structure can limit independent wanderings to a more focused goal of the specific module and support for its interface to the rest of the system.
The SPM can get verification of their assumptions by scheduling goals and sub-goals that focus on filling in the design architecture and calling for informal reviews to discuss what are we trying to do and why is it not getting done.

Master/Apprentice Programming
Have no more than one or two Apprentices per Master or your Masters will not get much of their own work done.
Masters spend a minimum of one hour per week with their Apprentices in individual one-on-one meetings. These can be in a conference room with white boards or at either's work station. The emphasis is on information exchange, hence the white boards and work stations.
As with many one-on-one training systems, the topic is along the lines of "How are you doing this" vs. "How I do (did) this" in a corrective, suggestive, and evaluative context. Some times the Master can learn from the Apprentice.

In general, and from experience, most processes are developed by people who never have or had to use them. At the higher levels of certification, the capabilities and maturity groups require that processes be developed according to a written process and all processes are to be tested with focus groups or small targeted projects to validate the process BEFORE it is imposed upon the masses.
The arguments of "Follow the process or Get the work done?" can be minimized by having well thought out processes AND having the people who will use the processes provide feedback before being tasked to follow them. This can lead to a smoother transition from old way to new way and gives a greater probability that the new methods will be followed and adopted into the corporate culture.
In addition to all of the above, do not forget to plan how training will be managed to maintain the processes.

Software Environment Planning Using First Principles
The software development environment should be set up based on first principles of the business requirements. Here are some examples.

There are many more first principles and most project include several. Many times they conflict with each other and trade-offs must be made. The basic approach is to list all of them during a team planning session and prioritize the list. This should result in a good reference to help in planning the software development environment.

Project Planning Using First Principles
Training Session Example
Target: AARAM Missile Radar Head
What are the most important systems features? (Marketing Engineering)
List these for display.
What are the most important systems level capabilities? (System Engineering)
List these for display.

These are two different areas although they can impact each other. They must be kept separate to allow a stable design to be developed.
Discuss this concept.

What drives the design, where are changes likely to occur, where are the risk areas and why are they risks?

Improving the Quality of Software Engineers
Software Engineers should go through the same process as medical doctors. There should be an internship at any company they work for that consists of learning the current tools, development environment, and integration processes that are standard for that company. They also learn how development teams work, the review processes, and design practices that are acceptable.

Sample Project
Here's 3 million dollars, office space, lab space, and computers for managers, engineers, and admin support. The task is to develop flight control software for an auto-stabilized hovering vechicle. The hardware is COTS with some sensor augmentations.
What do you do?

Identify Your Deliverables and Who They Go To
The end customer is rarely the only entity to receive something from the project. Work Products (WP), outputs of the project, can be sent to Quality Control (QC), Configuration Management (CM), system integrators, marketing and sales, accounting, and other business units. Not all of these are code, most are documents with different formats. Each WP should have a procedure describing how it is produced. Establish these early in the project. They usually are defined at the corporate level and are designed to be modified to fit a given project.

Four Stages on Using Procedures from "Action in an Organization" (Nels Pearson,1987)
When tasked to do activities for an organization, rather than complain about how things are done, try these four steps.

Evolution vs. Intelligent Design: Better Software Through Active Leadership
Early in a project, it was found that helpful information could be sent to the output window of the debugging tool by use of the printf() function. This is a common practice in many software projects. As the project continued, more and more programmers used this method to provide status and error information about their section of code. Because this type of output was not planned for, it "evolved" into a non-uniform jumble of output text that few but the originators could decipher.

With regards to software, leave "Evolution" in the 19th century. "Intelligent Design" is a much better approach.

Making The Hardware Team Happy
If you want to please the Hardware Group, insist that the system run "Light the LED" code first. By demonstrating deterministic control over the hardware, the majority of the problems later on can be arguably related to software. Having a stable and well tested hardware/software interface early in the project can let software engineers focus on software and hardware engineers focus on hardware. The Hardware Group can also run the "Light the LED" code to verify that they haven't broken the interface that the software relies on.

For hopeless projects, at least try to use better bubble gum, bailing wire, or duck tape each time you're ask to make a change.

Integrate Hardware and Software Early and Often
Few things are more frustrating to Software Engineers than unstable or faulty hardware. Good hardware, like good software, is rarely successfully developed in isolation. Many projects are parallel efforts of developing new hardware and the new software to go with it.
One sub-section of the Integrated Product Team is the Hardware-Software Interface section. This section is responsible for developing test suites to verify that the hardware will perform at directed by the software. The section, for small projects, could also be responsible for the development of the hardware specific drivers and hardware development test code. A key area is working with the hardware engineers on developing the hardware interface definitions to minimize the complexity and improve the robustness of the hardware interface drivers.
They can also be involved in developing simulation hardware and software to help systems engineer model the product to explore proposed module interfaces and system performance.

Computer Programming
Is the ART and SCIENCE of moving the bits in the computer's memory from one area to another and sometimes changing their states before or after they move. The ART is picking which SCIENTIFICLY proven method to use and being able to justify why that method was the best.

Meetings: Donuts and Cookies Rule
As a token effort to show concern for employees, the company (under the Employee Moral Charge Number) should provide donuts for any meeting held before 9am and cookies for any meeting held after 4pm. Nit pickets could exclude meetings called for 9:00 or 16:00 and argue that the meeting times have be before or after the times stated.
Others are the Lunch Meetings Require Pizza and the Deli Sandwiches or Take-Out For Weekend Workers rules.

The Architect, The Carpenter, and the Team - A Model for Product Development
The Architect knows exactly what the end product will look like in terms of structure, performance, features, interfaces, etc. The Architect can answer any question the customer could raise as to how the end product will meet the customer's expectations. These questions are not limited to the product itself, but include support, test, training, maintenance, etc.
The Carpenter knows what parts and pieces are needed to provide those characteristics and how to build those items.
The Team includes the administration and managerial support to generate a development project. Logistics, resources, personnel, scheduling, monitoring, and all the worker bees make up the Team.
In a modern view, the Architect might be the Chief Systems Engineer. This person is the principle customer interface for all requirements and technical obligations. If it pleases the Architect, it will please the customer. The Carpenter might be the Chief Software Technologist or Project Technical Lead. This person is responsible for leading the effort to develop the technology needed to meet the Architect's vision and works closely with the Architect to insure that that vision is technically feasible.
In a large project, both the Architect and Carpenter will lead small groups of leads that in turn command one or more small groups. (i.e. The Team)
Another view, from Sports, is to see the Architect as the Team Manager, the Carpenter as the Team Coach, and The Team as the Players and the Front Office. Even here, there are sub-managers, sub-coaches, and lots of others.
The KEY point is that this model is based on three elements: Someone who knows what needs to be done (The Architect), someone that knows what it takes to do it (The Carpenter), and a bunch of people to get it done (The Team).

How to Succeed in RADAR without Really Trying
Model your system first and explore all the data paths.
Simulate any hardware that doesn't exist.
Show that your model will pass the data from end-to-end in ALL of its configurations, modes, features, and options.
For complex hardware, assign a software team to develop drivers and FULLY exercise the hardware so that no surprises occur when the operations software is applied using those drivers.
Replace simulated modules with real hardware once it has been verified and integrated with software drivers.
Make sure that interface documents are stable as early as possible since any changes could ripple through the entire system and cause all prior testing to be nullified.

The Easiest Way to Get People to Work
Make a Work Queue (WQ). Each task is described and has completion criteria. All notes, bug reports, test, etc. are added to the WQ object so that if someone else wants to continue the effort, they have all the information they need.
(Author's note: I used a similar method of assigning work in the mid-90s where I would list the functions needed for the week and include a list for functions needed next week. A list was generated for each programmer. If they finished this week's list, then they could start on next week's.)

The Great Divide: Turning Developmental Code into Product Code
In many cases, developing software is like scientific study. An idea is generated based on some prior knowledge and experiments are performed to verify the idea. Since the main emphasis is to verify the idea, less effort is made regarding structure, robustness, ease of use, performance, and quality in general. (see also Why Software Takes Longer). Unfortunately, many managers think "The code works so therefore it's done, right?." Wrong. About the only code that could be "done" in this context would be a quick "Hello world." program to show someone how to compile and link using command line gcc.
Deliverable code for a product requires a vetting process with a level of documentation consistent for its use.
Using first principles (see also Software Environment Planning Using First Principles), generate a prioritized list of characteristics that the product software must have and why and then use that list to qualify code for release.

Example: Robustness
Fail-Safe or Fault Tolerant: Should the software fail safely and stop or should it try to recover from errors and continue to run?
Run Time Checks: At what level of the code can the inputs be trusted such that run-time checks are not required on the input data?

Now, back to the main topic. Consider a two stage process: A loosely controlled code development processes to discover how to do the software task and a tightly controlled code development processes to convert the developmental code into a deliverable product.
Demos can be made with the developmental code, but only the output of the tightly controlled process is allowed to be released.
The advantage to this method is that visibility is gained quickly as to which ideas work and how the code modules interact without the overhead of formal peer review, formal documentation, formal configuration management, etc. on code that may be thrown out or mostly rewritten in the next day or week. Why? Because it is theoretically impossible to predict exactly how software will interact until it is run on a system.
However, once those interactions are understood, the process of refactoring the code into a robust product is fairly straight forward. And the insight gained should allow for a better solution, if needed, to be generated.
Design reviews can now be conducted based on evidence rather than conjecture. Module interactions can be analyzed and interfaces can be engineered rather than guessed at.

Quick Requirements Check
Walk through the requirements and put together a strawman design that would meet them. Indicate how each requirement would be tested. How close to the reference architecture did the strawman come? What 'holes' were discovered?

Viewing the Future as the Past
This is a planning technique that can help generate better development plans, uncover hidden tasks, and unforeseen project resource requirements.
Gather your project leads and senior staff together and set the clock to one month after the delivery date. Now, have each person try to describe how their area of the project went. Example topics to cover could include:

This process obviously relies heavily on the level of experience of your staff and their collective imagination, but it is usually productive in that it can identify risk areas and gaps in the current project plan and schedule. As a follow on, compare the imagined project's history with the current project's progress.

Follow on Projects Require Follow on Expertise
Many projects leverage off a prior project by extending its features to meet a new mission statement or develop a new mode of operation to be used with its core capabilities.
Unless the base project was completed to a finished and deliverable product (i.e. fully tested, independently buildable, and was well documented, both technically and with user guides, manuals, and examples), the new project team should include members of the base projects development team to insure that it has the corporate technical knowledge base to succeed.

The Short War
Planet Noehtyar and planet Yugwen were moving twoards war and both embarked on upgrade projects for their military.
Noehtyar's development system used a matrix model where the section managers tried to support groups of multiple project engineers without knowing the details of what those engineers did, but only the basic skills that they needed, and used functional managers that didn't need the technical expertise to understand their projects but focused on tracking schedules and EVMS charts.
Yugwen's used a hierarcal model where the manager at each layer of the overall structure had the expertise to understand the technical aspects of the projects and the authorization to select engineers with the background and experience to do the detailed work of the next layer below. Based on their project experience and technical background, they could evaluate their schedules, come up with probabilities of success, adjust resources as needed, and used their EVMS as a tool to validate changes made.
After five years, Noehtyar was ready to deploy their system that had most of the initial features and many lesser ones that were added in the last year. However, Yugwen had deployed their system three years earlier and had been continually testing and training with it.
It was a very short war.

Six Sigma
Why is it difficult to generate a six sigma project topic?
If you have been evaluated as having an understanding of six sigma methods, why do you need to develop your own project to demonstrate that knowledge?
What's the difference between writing a procedure, that should have been part of the Software Development Plan (SDP), or generating a file management utility, that should have been part of the programs development process, and a six sigma project that does the same thing?
Asking non-manager personnel to come up with their own six sigma project is like asking a private to come up with solutions as to why the war isn't being won.
A private could comment that the guns might work more reliably if the ammo wasn't dropped in the mud, but shouldn't the sergeant already know that? Should the private be expected to evaluate the deployment of troops and suggest an evaluation process to determine the effectiveness of the strategy? How well would that be received at command?
Why aren't managers creating lists of tasks that, although not covered by their contacts, could improve productivity or reduce waste on their program? Self-interest: No one likes to admit that their program processes need improvement.

Problem Statement:
Most of the meetings that I have attended, at the project level, did not have a written agenda, resulted in no decisions made, no actions to be taken, and did not have meeting minutes recorded.
Figure a thousand dollars of productivity spent for each meeting without any record of value received.

Would it be a six sigma project to suggest investigating ways to improve meeting management?

Model Based Schedule Tracking
Use a System Model to track progress by indicating the status of its infrastructure and the components within the model.
Generate a block diagram of the system and highlight the infrastructure components and all of the I/O and processing modules.
Flag each of these areas with Green, Yellow, or Red as used for EVMS tracking. Could include White for Not Started. They could also be marked as to Phase (design, code & test, released, etc.)
Every status meeting now focuses the team on what the system is suppose to do and how it is doing it.

First level of operability: Passing data from end-to-end

Second level of operability: Adding modules for signal processing
Third level of operability: Module group validation/integration.

Searching for the A Team
Reducing Wheel Reinvention with Effective Reuse of Corporate Knowledge
Successful programs are usually the results of key individuals leading others to do or themselves performing outstanding work. These key individuals are also the main repositories of the corporation's knowledge on how to successfully complete a program.
Effective Use of Your A Team People: Three Columns

Successful Programs Key Individuals of
the Past Involved
and Expertise
Where are they now?
-- -- --
Survey the program members to discover your A team.
Group staff into three categories.
A Team: Key individuals that contributed the most to the success of the program.
B Team: People that provided the supporting efforts that helped the program succeed.
More Training, More Experience Needed: Loss of these people would have had minor impact on the success of the program.

Use my form to tell me what to do
I made the form and put in the boxes, sections, and areas that need to be filled in to provide the information that I will need to get a job done.
Your form is based on what you want done, not necessarily on what I need to get it done.
My form will also contain areas for the relevant information from your form.
When I accept my completed form and agree to do the job, I am saying that I have all the information that I need to do your job for you within the time agreed to.
Giving me your form is just an indication that you would like to discuss a job that you would like done. There is no commitment being made on my part.

Can Reuse Succeed?
Process of assessment
1. List main products lines.
2. List primary products and show their architecture.
Note evolution or pedigree.
3. List product subsystems and show their architecture.
Note software language, OS, hardware, processor, memory, environment (airframe, desktop, missile, space, mobile)
4. Evaluate reuse effort.
What was reused? Architecture, design, code, test system, external support, etc.
NOTE: The experience of developers can also be reused, but you have to talk to them.

Question: Did the Architect/Design Lead talk to anyone who has worked on this type of project?
(see Searching for the A Team)

hmm...more thoughts

Ultimate reuse: Code library
Typical reuse: Source code examples.
Typical reuse: Reference designs with supporting theory papers.
Typical reuse: Project document examples. SDP, SDD, PDR slides, CDR slides, STP, etc.
Typical reuse: People who know how to do this.

1. What items do your projects typically reuse from past or current projects?
MA: Project documents like the Software Development Plan (SDP) or a Software
Test Plan (STP). Source code examples, if well commented. Third party libraries and reference manuals.
2. What would you like to find in a Reuse Repository?
MA: Project documents with comments as to why selections or decisions were made for the various document sections.
Source code examples with notes as to structure, variable use, and algorithm selection decisions.
Useful code libraries with reference manuals that includes examples of use for each function.
3. What would make a Reuse Asset useful to your project?
a. Code library asset.
MA: Should include verification suite or test plan. Source code would be useful also. Treat as open source.
b. Source code asset.
MA: Well commented and should include a developers notebook file to help understand the coding style and structure.
c. Reference design asset.
MA: Notes on decisions made in the design tradeoffs, pros and cons, and considerations. Memory use analysis. Run-time estimates, etc.
d. Project document asset (SDP, SDD, STP, SR, ADD, etc.)
MA: Project documents with comments as to why selections or decisions were made for the various document sections.
e. Subject Matter Experts (SME) list.
Contact information and background.
4. Does your project consider using reuse when developing software?
MA: Personally, yes. Project level, unknown.
5. Does your project consider applicability for reuse during software development?
MA: Personally, yes. Project level, unknown.
NOTE: The WHY something was done can be as important as WHAT was done.

Do You Know Reuse When You See It?
Models of reuse
Based on lessons learned from previous attempts or detailed analysis.

Reuse of Architecture
Enough detail to generate a product that performs the generalized task. A Basic Architecture has key concepts, elements, and the organization of elements.
The Reusable Architecture establishes a sound starting point for development.

The Automobile
A large rectangle (body), one engine with drive train to rear axle, four wheels, one steering wheel, two head lights, and two tail lights.

The Story
Character introduction, crisis, failure, discovery, crisis, success, and so on.

Reuse of Design
Enough detail to generate a product that performs a specified task. The Reusable Design defines a known proven method of implementation, but can still be modified to fit a specific need.

A Basic Design includes details of implementation
The Number 2 Pencil
A wooden shell, lead (graphite) insert with point, and optional eraser.

Reuse of Product
The product is used, unmodified, as a component for a larger system.
A Goodyear radial tire for a 16 inch wheel rim.

Each of these areas has a different emphasis of use, but as the project develops, they tend to morph from one area into the next. An Architecture becomes a Design which develops into a Product. If Reuse is in the mind of the developers, then partitions may be established as to where one area of development ends and the next one starts.
Reviews could then be held to determine if there is too much or too little detail in the Architecture, Design, or Product to be a reusable workproduct.
If it is agreed to that the work-product is reusable, then additional documentation is generated to guide others on what it is needed to efficiently reuse the work-product.
A current example of this would be the Tailoring Guidelines for a Software Development Plan.

Programs need a Support SPM
The Support SMP provides needed organizational support for small IRAD and Demo programs that have a software component of a few thousand lines of code. These developments may have only one or two software engineers supporting a chief engineer and a systems engineer, but they still need someone to help them organize their software effort.
The Support SPM can help:

Without an experienced SPM, the program passes down the task of setting up their development environment to the software engineers who may not have the training, background, or knowledge.
The Support SMP would meet with the team and may spend 10 hours in the first week assisting them in deciding what is needed and developing a general development plan. Then a few hours more coordinating the setup. After the work is in progress, the SPM provides a point of contact for other software needs and can drop by as needed to adjust plans and make suggestions to processes being used.

One of the major demons of software and systems in general is complexity. Its nemeses are reuse and standardization. Although complexity is normally applied to coding logic, it is also relavent to naming.
Using descriptive names for variables is good. Using a typedef of a base datatype should be justified.

(SPELL Checked to here)

Who Should Write Documents?
The short answer to this question is, Everyone, and in most companies, anyone can be given the responsibility to write the documentation, manuals, guides, and references for their project. Is it any wonder, then, that documents are about the last thing to be produced in a project and tend to be one of the biggest annoyances to an engineer?
a. Find an old document of the type you need to write and cut-n-paste content.
b. Train yourself on all of the documentation tools, company standards, and author guides.
c. Contact the Technical Writer assigned to the project for guidance and assistance.
If option c were available, the productivity level and quality of document work products would take a quantum step to the plus side. In most cases, though, option a is the normal selection.
Since many companies do not train all of their engineer to be formal documentation writers, they may hire technical writers, but then only assign them to the most visible tasks such as proposal writing support or customer contracted deliverable work products. This can limit their usefulness.
A simple improvement would be to have them reserve from one to four hours a week to be available to any project that needs technical writing support. Another option would be to have a general pool of technical writers. This would provide engineers with a resource that is up-to-date on document processes and procedures, improve document standardization, and reduce rewrites. It reduces the task for the enginner from figuring out all of the requirements for the document to fill-in-the-blanks with content.

Technical Writers:
Familiar with the company's authoring and document formatting tools such as Microsoft Word, PowerPoint, and LaTex.
Knowledgeable about company documentation standards and templates.
Establish the format and organization of the document, but not the contents.
Assists in the presentation of the information by suggesting style and form of the content.

"It is easier to optimize working code, than to make optimized code work." -Annonimus