Dying is Easy, Software is Hard (with my apologies to Comedians)
Nels Pearson, 12jul08
rev: 04sep13

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, well...you 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:
	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 setting 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.c		con 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.
	Example:
		?? Change process order to scan block for zeros before processing
		## minor timing improvement (2.6 us)

Experiment
	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.

Management
	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.

Questions
	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.

Estimation
	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.

Teams
	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:
	What does the User Interface look like?
	How does the data flow through the system?
	What format is the data in?
	What memory constraints are there? What memory requirements?
	What bandwidth impacts are there?
	
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.

Processes
	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.
Is it most important that the software be developed quickly?
Use a well known standard tool chain that all of the team members have experience with.
Is it most important that the software expand the capabilities of the company?
Consider using the newest tools and training core people that can train others.
Is it most important that the software be robust and work with minimal errors?
Focus on peer reviews during all stages of development, especially the architecture phase and design phase.
Is it most important that the software be easy to upgrade and add features later?
Develop several use cases to explore how an upgrade could occur, who's involved, what tools are needed,
and walk through a simulated process from end to end.
Is it most important that the software meet safety and/or security guidelines and requirements?
Include experts in these fields early on in the architecture and design phases and have them review final
implementation and test.
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
	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. 
	First, use the system that is in place for doing the activity requested. 
	Assuming that this activity has been done in the past, it was probably done in this fashion.
	Second, try to make the system work if for some reason its methods don't seem to get the job done.
	The rational here is that the system may have worked in the past, but parameters for the activity may have changed
	over time and the system may need adjusting to meet today's needs.
	Third, see what parts of the system do apply to the activity and use those. Throw out those that don't apply
	or work around them.
	The idea here is to make it LOOK like you're using their system to get the job done. 
	Fourth, when all else fails, develop a new system.
	The system maybe so out of it that it should have been discarded years ago, but all the sheep before just kept doing
	the same thing and ignoring the results. Just make sure that the activity you do is the one that gets the task that
	they gave you to do accomplished.

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.
		How can this "useful" practice be brought under control?
		What could have been done to control its "evolution"?
		What phase of the project should this technique have been discussed?
	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:
		How did the work progress?
		What was the development environment like?
		What did the team members complain about?
		What could have been done to bring new team members up-to-speed faster?
		What was integration like?
		What was the response when the network went down?
		What could have made the PDR, CDR, and other presentations better?
		What could have been done to reduce the schedule slips?
	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
		Validates interfaces. Modules are pass-through placeholders.
		Validates messaging scheme and data structures.
		Provide baseline throughput timing values.
		Reveals data movement bottlenecks.
		Reveals data flow controllability issues.
		Verifies instrumentation points and capabilities.
		Allows evaluation of real-time control and operation of hardware with software.
		Allows early evaluation of error reporting, handling, and recovery processes.

	Second level of operability: Adding modules for signal processing
		Allows "Unit Under Test" validation.
		Allows partitioning of work based on module complexity.
		Allows status in discrete easily identifiable units (modules).
		Supports continuous integration.
		Supports auto-code generation of modules by external software products.

	Third level of operability: Module group validation/integration.
		Tests modules as groups with the groups growing until the entire system is covered.
		Supports continuous integration.
		Allows collection of intermediate data to validate algorithms and controls.

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			Where are they now?
of the Past			Involved and Expertise
- - - -				- - - -				- - - -

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 A_team.rtf)

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.

Survey:
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:
•	Acquire computer assets
•	Select software tools
•	Set up a streamlined CM plan
•	Set up a simple development plan
•	Track software progress
•	Suggest work products that should be developed
•	Suggest QA methods base on the work products to be delivered
•	Help organize peer reviews using personnel from overhead or other programs
•	Provide expertise regarding Software Licenses and Points of Contact for popular tools
•	Recommend FOSS tools and other support items

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.

Complexity
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?

Options:
	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.

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