Top 10 cameras on Flickr
Top 10 cameras on Flickr. Topping the list is Nikon (D50 and D70), followed by Canon.
Year: 2006
We feel fine
We feel fine analyses blog posts, and determines the current mood by gender, age and location. So you can see check if the mood of teenagers in London has improved this week. Amazing visualisations.
Facts and Fallacies in Software Engineering
People
- The most important factor in software work is the quality of the programmers.
- The best programmers are up to 28 times better than the worst programmers.
- Adding people to a late project makes it later.
- The working environment has a profound impact on productivity and quality.
Tools and Techniques
- Hype (about tools and techniques) is the plague on the house of software.
- New tools/techniques cause an initial loss of productivity/quality.
- Software developers talk a lot about tools, but seldom use them.
Estimation
- One of the two most common causes of runaway projects is poor estimation.
- Software estimation usually occurs at the wrong time.
- Software estimation is usually done by the wrong people.
- Software estimates are rarely corrected as the project proceeds.
- It is not surprising that software estimates are bad. But we live and die by them anyway!
- There is a disconnect between software management and their programmers.
- The answer to a feasibility study is almost always “yes”.
Reuse
- Reuse-in-the-small is a well-solved problem.
- Reuse-in-the-large remains a mostly unsolved problem.
- Reuse-in-the-large works best for families of related systems.
- Reusable components are three times as hard to build, and should be tried out in three settings.
- Modification of reused code is particularly error-prone.
- Design pattern reuse is one solution to the problems of code reuse.
Complexity
- For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
- Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
Requirements
- One of the two most common causes of runaway projects is unstable requirements.
- Requirements errors are the most expensive to fix during production.
- Missing requirements are the hardest requirements errors to correct.
Design
- Explicit requirements “explode” as implicit (design) requirements for a solution evolve.
- There is seldom one best design solution to a software problem.
- Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal.
Coding
- Designer “primitives” (solutions they can readily code) rarely match programmer “primitives”.
- COBOL is a very bad language, but all the others (for business applications) are so much worse.
Error-removal
- Error-removal is the most time-consuming phase of the life cycle.
Testing
- Software is usually tested at best at the 55-60 percent (branch) coverage level.
- 100 percent coverage is still far from enough.
- Test tools are essential, but many are rarely used.
- Test automation rarely is. Most testing activities cannot be automated.
- Programmer-created, built-in, debug code is an important supplement to testing tools.
Reviews/Inspections
- Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
- But rigorous inspections should not replace testing.
- Post-delivery reviews (some call them “retrospectives”) are important, and seldom performed.
- Reviews are both technical and sociological, and both factors must be accommodated.
Maintenance
- Maintenance typically consumes 40-80 percent of software costs. It is probably the most important life cycle phase of software.
- Enhancements represent roughly 60 percent of maintenance costs.
- Maintenance is a solution, not a problem.
- Understanding the existing product is the most difficult task of maintenance.
- Better methods lead to MORE maintenance, not less.
Quality
- Quality IS: a collection of attributes.
- Quality is NOT: user satisfaction, meeting requirements, achieving cost/schedule, or reliability.
Reliability
- 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
- Efficiency stems more from good design than good coding.
- High-order-language code can be about 90 percent as efficient as comparable assembler code.
- There are tradeoffs between size and time optimization.
About Research
- Many researchers advocate rather than investigate.
Fallacies in Software Engineering
About Management
- Fallacy: You can’t manage what you can’t measure.
- Fallacy: You can manage quality into a software product.
People
- Fallacy: Programming can and should be egoless.
Tools and Techniques
- Fallacy: Tools and techniques: one size fits all.
- Fallacy: Software needs more methodologies.
Estimation
- Fallacy: To estimate cost and schedule, first estimate lines of code.
Testing
- Fallacy: Random test input is a good way to optimize testing.
Reviews
- Fallacy: “Given enough eyeballs, all bugs are shallow”.
Maintenance
- Fallacy: The way to predict future maintenance cost and to make product replacement decisions is to look at past cost data.
About Education
- Fallacy: You teach people how to program by showing them how to write programs.
These are from Robert Glass’ book Facts and Fallacies in Software Engineering.
Multicriteria decision making
Decisions are usually based on multiple criteria. You have to trade off between criteria. I’ve been involved many such decisions over the last 5 years.
Example 1: A conglomerate wanted to identify industries for growth. We shortlisted 19 industries, identified 12 criteria for the attractiveness of an industry, researched each one and plotted them on spidergraphs like below.
The intention was that, to identify the most favourable industries, you’d just pick the ones with the largest filled area.
Example 2: Another time, we had to decide among BPO vendors. Again, we picked a bunch of criteria and compared vendors against these criteria.
Example 3: Once, we had to identify stakeholders’ position on a project.
Those who were big on the right of the graph were for, and those who were big on the left were against.
In all the above cases, the same process was used for decision making.
- List criteria exhaustively
- Evaluate options against each criteria
- Assign weights to criteria (equal weights implicitly assigned above)
- Compare options
Having applied this methodology it several times, I am convinced this process is fundamentally flawed. See how in this post: Errors in multicriteria decision making.
Tube announcements
I was travelling on the Jubilee line, just pulling into Stratford (the last stop), when I heard this announcement.
“The next station is Stratford, where this train terminates. Thank you for travelling on the Jubilee line, and I hope you have a very pleasant evening.”
(pause)
“Unless, of course, you were the person who pulled the passenger alarm at Westminster, in which case I don’t care what kind of an evening you have.”
In-cell Excel charts
Juice analytics has some Excel graphing tips. You can make charts like below without using charts, using just text.
These are useful because the charts are aligned with the data.
I once used a similar technique to display people’s staffing position. The sheet below lists people, projects they’re on and how long they’ll be on. The coloured cells to the right are a calendar display of the same stuff. Makes it easy to read.
The trick is to place each week for each person as a thin cell, like below. Then the cell is populated with a formula that makes it 0 or 1 depending on whether the person is available that week or not. (The blue row #2 stores the start date of the week, and I compare this with the end date of each person’s project.)
And then, you can turn on conditional formatting.
How iPods work
How iPods work: how the wheel and the software inside Apple’s iPod work.
Knuth Volume 4
The Art of Computer Programming, Volume 4 by Donald Knuth. Pre-fascicles are available for download.