11 Oct 2012 at 21:17
Looking to chemistry this time, here are six proposed Rules of Reproducibility.
- Were studies blinded?
- Were all results shown?
- Were experiments repeated?
- Were positive and negative controls shown?
- Were reagents validated?
- Were the statistical tests appropriate?
Many science papers are unfortunately weak when it comes to these rules, and in many fields #2 is a real problem - only the positive results are shown, the rest are hidden away and never seen.
05 Oct 2012 at 20:29
Dreamhost upgraded their servers to Rails 3.0.3 but this blog runs on a much older version.
I really need to upgrade this blog software when I get the chance
16 Mar 2012 at 16:53
Found another interesting parallel between software development and running. The field of running and exercise is full of lots of claims about special ideas that will drastically improve performance of athletes. The Science of Sport site has a blog post on How to spot bad science and fads- Determining whether an idea is worthwhile
At a recent track meet I was having a conversation with a friend in college, who made the astute observation that if the coaches inserted random scientific terms to explain things, even if they were totally wrong, the runners seemed to buy into it more enthusiastically. That’s a very common reaction, we all do it. We associate science and complexity with being smart or correct. As I’ve said before…people trying to fool you go from simple to complex…good coaches translate complex things into simple understandable ideas.
In another post the same site talks about the value of research, theory and practice
… I often rely on what one of my Professor’s, Jason Winchester, called the three stool leg test. You have research, theory, and practice. If you have all three, it’s almost certainly a good idea to implement it. If you have 2 of 3, it’s fairly likely that it works and it depends on the strength of the 2. If you’ve only got 1 of 3 going for it, it probably doesn’t work. The beauty of using the 3 stool leg test is it blends science and practice, and compliments it with theory which in itself is a blend of science and practice.
17 Feb 2012 at 16:34
Jim Bird has taken a look at how much is technical debt costing you. Nice to see that he ignores the dollar estimates per line of code that some authors use and just uses a simple $$$ through to $ notation.
$$$ Making a fundamental mistake in architecture or the platform technology – you don’t find out until too late, until you have real customers using the system, that a key piece of technology like the database or messaging fabric doesn’t scale or isn’t reliable, or …
$ Missing or poor error handling and exception handling. It will constantly bite you …
06 Feb 2012 at 14:44
Recently Jim Bird had to point out that Source Code is an Asset, Not a Liability. Unfortunately it means that there are people in the software development community that are not aware of the literature - specifically Howard Baetjer Jr.’s Software as Capital.
15 Jan 2012 at 18:46
Some interesting lessons for Software Development can be obtained form outside our field. I was reminded of this while reading a running blog that looked at what lessons could be gained from outside of the field of running coaching…
Rules of Everything
- When something is new or gains popularity, it is overemphasized until it eventually falls into it’s rightful place. How long that process takes varies greatly.
- Research is only as good as the measurement being used is.
- We overemphasize the importance of what we can measure and what we already know, ignoring that which we can not measure and know little about.
- We think in absolutes and either/ors instead of the spectrum that is really present.
Point 1. helps explain a lot of the original hype/hope surrounding the agile approaches to software development.
Lessons from outside the running world
We go through a cycle of forgetting and remembering what’s been done before us. You see this in the reintroduction or rememphasis in certain training methods in the coaching world. That’s why it is incredibly important to know your history. And if you can, know your history from a primary source where you attempt to look at it through their eyes during that time period. For example, going back and reading Lydiard’s original work gives a greater appreciation of what he was trying to do, then reading someones summary now, 50 years later. We lose a little bit of the original message.
Sometimes there is useful information available from looking back at what worked in the past. Although many on the software field seem to try to forget the past, the pioneers in the field learned a lot, some of which is still applicable to our present circumstances.
09 Jan 2012 at 22:15
Don’t normally link to Dave winer, but his The bosses do everything better is priceless…
When he looked at the code he must have been shocked to find something complex and intricate. Why isn’t the source code as simple as the software? Hah. When you figure that out let me know.
27 Dec 2011 at 20:12
All too often in software development I hear the comment that there must be a “simpler/easier way.”
Unfortunately, although sometimes simple solutions are workable, in most cases the simplest solution is not workable. Or rather the simple solution would be workable in some circumstances, but not for the current project becasue of some fairly obvious deficiencies in the simple solution.
28 Oct 2011 at 20:55
Seems strange to be linking to an article in Slate …
The mainstream media thrives on simple solutions. It has no idea whatsoever of how to report on a story that isn’t about easy fixes so much as it is about anguished human frustration and fear. The media prides itself on its ability to tell you how to clear your clutter, regrout your shower, or purge your closet of anything that makes you look fatâ€”in 24 minutes or less. It is bound to be flummoxed by a protest that offers up no happy endings.
Definitely no easy fixes when three slow moving changes are coming together - concentration of wealth, climate change and peak oil – it is as if we are running into the Limits to Growth
19 Oct 2011 at 20:58
From On Bullshit by Harry G Frankfurt:
In the old days, craftsmen did not cut corners, They worked carefully, and they took care with every aspect of their work. Every part of the product was considered, and each was designed and made to be exactly as it should be. These craftsmen did not relax their thoughtful self-discipline even with respect to features of their work that would ordinarily not be visible. Although no one would notice if those features were not quite right, the craftsmen would be bothered by their consciences. So nothing was swept under the rug. [pp 20-21]
02 Sep 2011 at 21:34
There is a famous saying in science: “extraordinary claims require extraordinary evidence.” In this case, the arguments for climate change are backed up by such an astounding degree of science and evidence, that one, or even a few, papers that claim to refute the science of climate change deserve careful scrutiny. As the author of Skeptico notes:
“Extraordinary claims require extraordinary evidence because they usually contradict claims that are backed by extraordinary evidence. The evidence for the extraordinary claim must support the new claim as well as explain why the old claims that are now being abandoned, previously appeared to be correct.”
18 Jul 2011 at 19:55
Some interesting parallels to Software Craftsmanship in Shop Class as Soulcraft. Focus is on working in the so called craft trades, specifically as Electrician and Motorcycle Mechanic.
Parallels are uncanny in the way that both books address Scientific Management, but Soulcraft found a very interesting quote from one of Ford’s biographers
So great was labor’s distaste for the new machine system that toward the close of 1913 every time the company wanted to add 100 men to its factory personnel, it was necessary to hire 963. (pg 42)
Small wonder then that Ford was forced to double the wages of the factory staff in order to retain workers. Of course this has since been spun as Ford wanting the workers to be able to afford the cars they were making, but it sure seems like it was a defensive move based on turnover.
09 Jul 2011 at 20:28
Now that the last shuttle launch has taken place, and with no replacement yet available, it is sobering to think that some bits of infrastructure are even older than the Space Shuttle.
Car and Driver have a report on the state of the interstate highway system and it does not sound good.
Now massive sections of the interstate, including almost all of â€‰them near major cities, have reached the end of their useful life; the interstates were designed to last 20 or 30 years, but now some areas are pushing 50 years and handling far more traffic than their planners anticipated. But as we reach into our wallets, we run into our generation’s big dilemma: We’re nearly broke.
In many ways the interstates are like the space shuttle. The design lifetime has been known for a long time, but the political will to put in the necessary investment to get a replacement available in time was not there. While the lack of a space shuttle is not critical, it does have major implications for the International Space Station, which can now only be reached by Soyuz rockets that were designed even earlier than the space shuttle.
Crumbling interstates and bridges are a much bigger concern since they affect how well the overall economy runs. Lose a major bridge as the Car and Driver report highlights, and suddenly life in a city grinds to a halt as people have to find alternative routes.
- What other bits of our infrastructure are aging and soon going to need replacement?
- Have we done the necessary investment to be able to build the replacements in time?
23 Jun 2011 at 21:34
Clearing up the climate debate
The Rolling Stone piece Climate of Denial
Not climate, but about useful questions for a different denial community from PZ Myers
23 Jun 2011 at 21:28
Why Software Development Will Never be Engineering
Basic idea in the article is that things like bridge building are now fairly static. The types of bridges we know how to build are well codified and replicable. Not mentioned in the article is that novel bridges still have novel problems, but after a few mistakes the construction engineers seem to resolve most of the issues.
Software development is different because it keeps on changing. The article argues that 10 years ago the future seemed to involve UML and CASE tools, but that the current state of the art of software development (Agile) does not use either of them.
07 Jun 2011 at 22:12
There is a constant refrain that occurs whenever people try to achieve anything
There must be an easier way
We learn this lesson at an early age and never forget it. The toy problems we are “challenged” with while learning always have an easy solution. Sometimes the easy solution is non-obvious and hard to find, but there is always a trick that makes solving the problem easy.
Unfortunately the world does not work this way — but we want to be tricked into thinking that it does.
- Finding the one food that will help the pounds melt away
- A pill that will cure all diseases
- The invisible hand of the market
- Buying a CASE tool to improve code quality
- Adopting Extreme Programming
- Thinking that Requirements Traceability makes systems better
Whether we think of these as “Silver Bullets” or a “Technological Fix”, it seems that we are hardwired to seek out simple solutions. In part this could be because we are so good at pattern recognition that we see a pattern where none exists.
All of this makes progress in software development difficult, because collectively we don’t want to believe how hard it is to deliver reliable systems. There has to be an easier way …
31 May 2011 at 23:01
Is there a Mathematics Generation Gap
Calculators became affordable in the mid- to late-1970s. Students in the 1980s were taught by teachers who had learned mathematics without calculators, and could do basic mental arithmetic. Students today might be taught by a teacher who is himself unable to work out 37+16 without help. The consequences are neatly described in an “Alex” cartoon I have on my fridge about a proposal to ban the use of calculators in school. “Faced with home work which requires him to work out simple sums in his head today’s lazy seven-year-old will instinctively turn to the quick and easy method of arriving at the answer… i.e. asking his dad, who, embarrassingly also wouldn’t have a clue without a calculator.”
Implications of this could be interesting for software development. When there is a large part of the workforce unable to do simple calculations without the use of a “Guessing Box” I expect there will be a lot more errors in software. Or at least errors that can be attributed to the Garbage In, Garbage Out problem of the users (and developers) not having the basic skills to detect implausible answers from systems.
24 May 2011 at 16:30
Brad DeLong admits to a problem
Four years ago we economists were writing learned papers about the “Great Moderation”: about how it looked as though the governing institutions of the world economy had finally learned how to control and moderate if not completely eliminate the business cycle–the epileptic seizures of the economy that leave us with pointlessly high unemployment, pointlessly idle capacity, and pointlessly rusting away machines in spite of there being no fundamental cause for machines to be idle, factories closed, and workers unemployed. In such an epileptic seizure of the economy, workers are unemployed and machines are idle because there isn’t the demand to employ them, and there isn’t the demand to employ because the workers are unemployed and have no incomes.
We have been seeing these epileptic seizures called business cycles fairly regularly since at least 1825.
And we have been claiming that we have it licked fairly regularly since 1825 as well.
British Prime Minister Robert Peel thought we had it licked with his Bank of England reforms in the 1840s.
While some of the explanations in that post are to my mind a bit off, the overall message is that economics is still not very good at predicting what will happen with the economy.
21 Apr 2011 at 11:04
An older article from The Atlantic, on
Management Myths. Telling comment from the viewpoint of Scientific Management
the science of handling pig iron is so great and amounts to so much that it is impossible for the man who is best suited to this type of work to understand the principles of this science, or even to work in accordance with these principles, without the aid of a man better educated than he is.
Worth a read if only for the historical perspective.