This starts with management because most of the high-leverage, high-visibility things that happend in sw are about it. Failure and successes are attributed to management.
Good management is more important that good techonology
Use the power of being a peon. (ref. The power of peonage).
Being a technologist is more fun that a manager. Managers sometimes forget what really matters which is people appreciation.
The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.
This is the eternul truth in software.
The "Capability Maturity Model" assumes that good process is the way to good software.
SEI People Capability Maturity Model less known, but talks about people, not process.
Technologists would prefer to invent new technologies to make out jobs easier. Even if we know, deep down inside, that the people issue is a more imporatnt one to work.
People are the key to success (Davis)
Sources:
- Principles of Software Development. (Davis, Alan)
The best programmers are up to 28 times better than the worst programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
Pay developers what they're worth. It's better to have a couple great devs than many that know less.
Swings back to the idea that people matter more than anything else.
Adding people to a late project makes it later.
Called the "Brook's law". When new people are added to late projects, a lot of time is used to bring them up to speed.
The working environment has a profound impact on productivity and product quality.
In order to be productive, a person needs a good working environment.
More information on : "Peopleware" by DeMarco, Tom and Timothy Lister.
Hype is the plague on the house of software. Most software tool and technique improvements account for about a 5 to 35 percent increase in productivity and quality. But at one time or another, most of those same improvements have been claimed by someone to have "order of magnitude" benefits.
Don't believe everything you read.
Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therfore, it is worth adopting new tools and techniques, but only (a) if their value is seen realistically and (b) if patience is used in measuring benefits.
How big is the learning curve or how much benefit is acquired after learning a new tool is impossible to estimate. Asking a peer that went through that practice helps to open perspective. Make sure to avoid zealots.
Software developers talk a lot about tools. They evaluate quire a few, buy a fair number, and use practically none.
One of the two most common causes of runaway projects is poor estimation.
- Give your best at estimating. Never optimistically estimate
- Requirements must be clear. If they change, estimate again.
Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements, are defined and thus before the problem is understood. Estimation, therefore, usually occurs ath the wrong time.
Most software estimates are made either by upper management or by marketing, not by the people who will build the software or their managers. Estimation is, therefore, done by the wrong people.
Software estimates are rarely adjusted as the project proceeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.
Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway.
Extreme programming: .. after the user choose three of the four factors
- Cost
- Schedule
- Features
- Quality .. the software developers get to choose the fourth.
There is a disconnect between management and their programmers. In one research study of a project that ffailed to meet its estimates and was seen by its management as a failure, the tehcnical participatns saw it as the most successful project they had ever worked on.
Projects where no estimates were prepared at all fared best on productivity.
There's a very strong correlation between level of productivity and a feeling of control. (When programmers felt in control of their fate, they were much more productive).
In other words, control-focused management does not necessarily lead to the best project or even to the most productive one.
The answer to a feasibility study is almost always "yes".
Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem
Controversy lies in the fact that too many people in the computing field think that reuse is a brand-new idea. As a result, there is enormous enthusiasm for this concept, an enthusiasm that would be more realistic if people understood its history and its failure to grow over the years.
Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
...
There is seldom one best design solution to a software problem
There are two key words in this fact: one and best. Most software problems con be solved in many different ways. That takes care of the one. And it is extremely difficult to know whether you have found a "best" solution, even if there were one. That should take care of the "best".
Software is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.
Programmers shift frmo design to coding when the problem is decomposed to a level of "primitives" that the designer has mastered. If the coder is not the same person as the designer, the designer's primitives are unlikely to match the coder's primitives, and trouble will result.
Error removal is the most time-consuming phase of the life cycle.
The construction of software is an exceedingly difficult and error-prone task. Wishes and "breakthroughs" and "silver bullets" will not change that.
Software that a typical programmer believes to be thoroughly tested has often had only about 55 to 60 percent of its logic paths executed. Using automated support, such as coverage analyzers, can raise that roughly to 85 to 90 percent. It is nearly impossible to test software at the level of 100 percent of its logic paths.
The problem is not so much that there is controversy about this fact and the implications, but that there is almost always insufficient attention paid to the testing portion of the software live cycle.
Unfortunately, the explanation for this is known and it comes back to tight schedules, low resources, bad estimates.
Even if 100 percent test coverage were possible, that is not a sufficient criterion for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent from the execution of a unique combination of logic paths. They will not be caught by 100 percent coverage.
It is nearly impossible to do a good job of error removal without tools. Debuggers are commonly used, but others, such as coverage analyzers, are not.
Test automation rarely is. That is, certain testing processes and and should be automated. But there is a lot of the testing activity that cannot be automated.
Automation is the ultimate trivialization of this nontrivial activity, and those who claim that it has been achieved are doing serious harm to the software field in its quest for better realistic tools and techniques.
Programmer-created built-in debug code, preferably optionally included in the object code based on compiler parameters, is an important supplement to testing tools.
Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run.
Research study after research study has shown that inspections can detect up to 90 percent of the errors in a software product before any test cases have been run. And that signifies an extremely effective process.
In spite of the benefits of rigorous inpsections, they cannot and shouldn't replace testing.
Inspection are a potent technique. But they are by no means enough for doing a complete job of error removal. Error removal is a complex task, and it requires all the armament the tester can muster.
Postdelivery reviews (or retrospectives) are generally acknowledged to be important, both from the point of view of determining customer satisfaction and from the point of view of process improvement. But most organizations do not do postdelivery reviews.
... most would agree that our field is so busy with its foot pressed to the gas pedal that it rarely has time to think about how it could be going better, not just faster. We speak of working smarter, not harder. But who has time to get in a position of working smarter ?
Peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster.
...
Quality is an elusive term. It's impossible to measure it and often depends on the context.
Quality is a collection of attributes
- Portability
- Reliability
- Efficiency
- Usability
- Testability
- Understandability
- Modifiability
Order is arbitrary and every engineer has it's own. Trying to make a generalized ordering of the quality -ilities is something like creating a good software design: If any two software people agree, they probably constitute a majority.
Quality is not user satisfaction, meeting requirements, meeting cost and schedule targets, or reliability.
A commonly accepted explanation of quality is that,
User Satisfaction = Meets requirements + delivered when neeeded + appropiate cost + quality product
That's a nice intuitive definition of user satisfaction, but since quality is involved, the equation becomes a flawed depiction. Quality, as we saw, is impossible to define in the context of software engineering. It's its own beast to grok.
There are errors that most programmers tend to make.
Errors tend to cluster.
There is no single best approach to software error removal.
Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
Efficiency stems more from good design than from good coding.
If there's a need for efficiency in a project, it must be considrered early in the life cycle.
To some eager programmers, coding is the most important task of software cosntruction, and the sooner we get to tit, the better. Design, to people in that camp, is simply something that puts off the ultimate problem solution activity.
There has to be a balance between the two.
...