09 Jan 2010 at 18:39
Since the trends on global CO2 levels are not good, I decided that it would be useful to watch how they are changing, The historical trend has been that on average we are increasing CO2 levels by approx. 1.9ppm/year. Based on this trend we will probably reach 400ppm in April or May 2015.
But we will see fluctuations up and down over the course of the year
This is a feature of the way the climate relates to the overall earth systems, the CO2 level drops as vegetation grows in the northern hemisphere summer, and then rises during the northern hemisphere winter, peaking in the spring, and then starting to fall off again in June. On an annual basis this fluctuation is around 6 ppm, but year on year we are averaging nearly 2ppm higher - but this varies with the economy and the weather in any year, hot years tend to be associated with a higher rise.
Below is sample data extracted from CO2Now.org which is also the source of the badge.
Overall this is a large scale experiment
How much CO2 can humans add to the atmosphere without adversely affecting the climate systems that we depend on?
08 Jan 2010 at 22:21
A historical look at what makes the GPL useful. Best quote
All you’re doing by whining about how the GPL makes it impossible to make money off of someone else’s work is to convince me that you’re…
Yes, it is a rant, but understandable in view of the rants and opinions raging about the GPL due to Oracle’s impending purchase of MySQL. For other views Groklaw explains The GPL Barter Cycle, Stallman on selling exceptions to the GPL - a follow up to the letter to the EU Commission, GPL Works No Matter Who Owns the Copyrights, Groklaw’s - Reasons I Believe the Community Should Support the Oracle-Sun Deal. In the end Groklaw comes out against the plan to make money from Open Source code by getting the EU Commission force it to go proprietary.
My personal take on the MySQL deal is that the time to have the concerns was when it was first sold to Sun, not afterwards by trying to revise the deal that Sun made when it first acquired MySQL.
For more background on Software, GPL and Patents there is always Groklaw’s GPL Resources and the amazingly detailed
An Explanation of Computation Theory for Lawyers, and for the historically minded, the ongoing SCO GPL case.
03 Jan 2010 at 14:37
After reading Mark Wilden’s tale of Why he doesn’t like Pair Programming I have spent some time reconsidering my Questions about Extreme Programming.
In the book I let Pair Programming off lightly, not fully addressing the dark side of pair programming that Mark addressed. Yes, chapter 9 is called Working at this intensity is hard, but I did not point out that after a full day of pair programming most developers are not in a fit state to do more work. XP requires a 40 hour work week so that the developers can recover from the pair programming.
Other problems I have noticed with Pair Programming
- Exploration of ideas is not encouraged, pairing makes a developer focus on writing the code, so unless there is time in the day for solo exploration the team gets a very superficial level of understanding of the code.
- Developers can come to rely too much on the unit tests, assuming that if the tests pass then the code is OK. (This follows on from the lack of exploration.)
- Corner cases and edge cases are not investigated in detail, especially if they are hard to write tests for.
- Code that requires detail thinking about the design is hard to do when pairing unless one partner completely dominates the session. With the usual tradeoff between partners, it is hard to build technically complex designs unless they have been already been worked out in a solo session.
- Personal styles matter when pairing, and not all pairings are as productive as others.
- Pairs with different typing skills and proficiencies often result in the better typist doing all of the coding with the other partner being purely passive.
Having said all of that, pairing is still a good way to show someone else around a codebase, and pairing is definitely useful when debugging code - the second pair of eyes definitely helps.
Questions about Extreme Programming that are still open
Overall I still see XP as a fairly niche methodology, as there are few projects that it is really suited for. The constraints of XP are fairly rigid, and although many projects have tried to replace the onsite customer with systems analysts, the decision cycle is definitely longer when the analyst is in the loop.
The key problem that XP projects face is that there is no real compelling case for using XP. Yes, some developers like it, but more for the Unit Testing rather than any other part, and the testing aspects can be replicated in any other approach to software development. I still think that the most useful parts of XP can be applied in other contexts.
Overall, although my questioning of XP was not well received at the time, I think it has stood the test of time well in that eight years on,XP is approaching the status of a footnote in software development history. Yes, it helped to motivate the Agile Alliance, but these days I see more projects trying Scrum than XP, and while some of the XP practices are here to stay, it is hard to point to any software that was developed using XP and state that it will stand the test of time.
Yes, many of the tools that supported XP practices will stand the test of time, but most (all?) were not developed as part of an XP project, instead they were solo projects undertaken to assist an XP team in one way or another.
In summary, although Questioning Extreme Programming is now outdated in that it refers to an earlier incarnation of XP, I still stand behind the claim that while it was an interesting approach to software development, it is not applicable to many projects, and the current versions of XP have similar problems. The ultra-light weight approach to software development that tries to put developers first does not work all that well in a corporate or entrepreneurial setting.
12 Dec 2009 at 09:59
Michael Pollan’s Eaters Manifesto - Eat food. Not too much. Mostly plants. has spawned another that looks at time management - Make lists. Not too much. Mostly do..
time managment is another totally overdone subject, wouldn’t it be great to have a similar credo to simplify all this hackneyed advice on to do lists, productivity, time management systems, and the like? Then, sent from the productivity heavens, it came to me:
Make lists. Not too much. Mostly do.
Nice parallels to software development here, planning is useful, but the key thing is actually crating the software.
10 Dec 2009 at 20:36
Tarmo Toikkanen has an interesting speculation about Why people still believe in the Waterfall model, putting the blame on the Royce paper that was trying to say that waterfall was not the way to do software development.
OK, so why do people still advocate the waterfall? If you look at the scientific articles on software engineering that discuss the waterfall, they all cite Royce’s article. In other words, they’re saying something like “The waterfall is a proven method (Royce, 1970).” So they base their claims on an article that actually says the opposite: that the model does not work.
Tarmo was not the first to run across this idea, but the interpretation of the problem is different.
Don’t draw figures or diagrams of wrong models, because people will remember them. And in the worst case that could cause hundreds of thousands of failed projects and billions of euros and dollars wasted for nothing.
Other people has written about The Waterfall Accident and Waterfall Model; not what was intended.
29 Nov 2009 at 16:35
Just found a very interesting post from Luke Halliwell on The Agile Disease that looks at the fit between Scrum and the game industry, but many of his points are relevant to other development domains.
[Agile] was designed by consultants, aimed squarely at the world of in-house enterprise IT: a world where mediocre developers work for large corporations that don’t understand software development, but can afford to buy in expensive consultants to â€œsaveâ€ their runaway projects.
Having daily stand-up meetings is ludicrous; it exists simply to protect against the dysfunction of team members that never talk to one another. … In anything resembling a normal, common-sense team, people will surely raise blockages with their manager as soon as they occur and not need to wait for a daily meeting!
After that rant Luke went on to describe what worked in his field, and even had a post after attending a Scrum Master course.
25 Nov 2009 at 19:11
Talking about why things are a lot more complicated than we might otherwise think.
Books are thick cos things are hard – Richard Denniss
A comment towards the end of his talk: ENVS1001 - Resources, Environment and Society - 2009 audio podcast, Week 05 Panel B: Can Economics Save the World? Richard Denniss (Fenner School of Environment and Society, Australian National University on iTunesU)
22 Nov 2009 at 22:21
Given that I do not agree with the characterization of software development as software engineering, it was somewhat of a surprise to find that there are a lot of parallels between software development and science.
Debugging and testing are probably the most scientific activities, in that developers have to make guesses about what is happening and then devise experiments to prove those guesses wrong. Developers also have to make predictions about how the systems they are developing will behave and then defend those predictions against speculations made by uniformed observers and occasionally defend against misinformation conveyed by financially interested parties.
One conclusion I could make from this is that the politics of software development are very similar to the politics of science. Practitioners try to pretend that there is no politics involved as it is all perfectly rational and understandable, but because people are involved it is all about politics. As soon as we start making predictions, then how we interpret those possible futures has a big effect on the actions we might take. This then becomes the realm of politics and it is that part that many software developers forget about (and many scientists as well) - Politics Matters.
We probably could have saved ourselves , but we were too damned lazy to try very hard … and too damned cheap. – Kurt Vonnegut
To celebrate the politics of science I’ve included a graphic reminder in the sidebar that small changes over a long period can result in a very interesting future.
11 Nov 2009 at 07:48
Seen a few useful blogs on documentation recently.
Jacob Kaplan-Moss has a good look at how the Django culture does documentation.
I especially liked this
Auto-generated documentation is almost worthless. At best it’s a slightly improved version of simply browsing through the source, but most of the time it’s easier just to read the source than to navigate the bullshit that these autodoc tools produce.
My take is that it is possible to produce readable and useful documentation using Rdoc or Javadoc, it is just that most projects do no take the time to produce good documentation. In many cases of Rdoc generated documentation all that is there is the signature to the method and a link to that excerpt of the code… not very useful.
17 Oct 2009 at 20:44
I met Chris Matts a few years ago and his REal Options ideas stuck with me but I never remembered to link to him.
His Blog is called decision-coach, and he has a very interesting approach to copyright
Terms and Conditions for Copying, Distribution and Modification
- Do whatever you like.
Chris seems to be going to be using a cartoon approach that shows promise, though it looks as if the book will have professionally drawn cartoons - personally I’d miss the hand drawn versions. The idea of when to design tests is covered in the Information Arrival cartoon, which is a long but worthwhile read.
08 Oct 2009 at 11:28
Seems that there is still a lot of resistance to using TDD.
Uncle Bob explaining the role of TDD in developing Fitnesse makes for interesting reading.
The bottom line is that TDD is a design technique but should not be the sole design technique. All the old design rules and skills still apply; and TDD is a powerful way to inform and augment them.
07 Oct 2009 at 22:09
Not much time to post recently, but have to note an interesting post about Software Artisans and Handmade Software
Had to smile at the thought the calling yourself a Software Artisan was pretentious. If they think that is pretentious what would they think about calling yourself a Software Craftsman?
03 Oct 2009 at 19:14
No Thanks Google
How Do I Disable Sidewiki?
Comments are deliberately turned off on this blog, but now Google wants to enable commenting via Sidewiki so that anyone can put comments directly in view while others browse what I have written.
NOT a good idea.
As Dave Winers says my Website Is My Space
Possible way to disable Sidewiki
Google site states “Sidewiki currently does not support comments over internal or SSL (https) encrypted pages.” So that might be a temporary fix - making the entire site SSL, but again there is the word “currently” which means that it might at some point allow for comments on SSL pages....
03 Oct 2009 at 07:23
Ivar Jacobsen has an interesting piece in Dr Dobbs - Why We Need a Theory for Software Engineering.
I’d have thought that 40 years after the initial NATO conferences on Software Engineering, someone would already have the theory well developed by now. Setting aside my bias for a while, teh article has some really good questions
Do we really know how to develop great software? The answer for many people is clearly yes. But do we know how to communicate and continuously improve the way that we develop software? Do we really understand the best way to communicate and share our knowledge?
Do we stand on quicksand or the shoulders of giants?
Have you ever taken the time to investigate a new method or practice only to find that it is just the re-branding and regurgitation of ideas that you have seen many times before?
Have you ever got frustrated that every new idea about software development seems to be at the expense and in aggressive competition with everything that has gone before?
Does it seem to you that following that latest software development trend has become more important than producing great software?
I sense a certain amount of frustration in these questions, because over the last 40+ years it sometimes seems that little progress has been made in our ability to reliably develop software. Admittedly my answer to these questions does not include the answer “Software Engineering”, but other than that I find I share the sentiment expressed in the article…
It is clear that we need to stop chasing after fads and easy answers that forever disappoint, and that we need to do it without discouraging innovation and the generation of new ideas. People need to stop constantly re-packaging and re-branding old ideas just for the sake of it. Instead they should focus on helping people understand how to build great software.
22 Sep 2009 at 20:28
Neil Tyson talks about the argument from ignorance
Beautiful quote from Neil - “Optical Illusions are Brain Failures”
Video on YouTube
22 Sep 2009 at 20:10
I just love this Joe the Developer doesn’t need a certificate from Gojko Adzic
What is really amazing about this particular time is that serious people whom I respect seem to be arguing for certification, with the idea that certification is coming anyway so it’s better if the community gets on board and influences it rather than ignoring it and suffering after. To that I can only say that people do drugs anyway but it’s still not OK for us to sell it to them.
It seems that there is now a move afoot to make Certified Scrum Developers… The World Agile Qualifications Board .. words fail me.
22 Sep 2009 at 20:04
Alan Cooper on Agile
“I’ve long been an advocate of such technological-craftsman-self-determination. It’s just that I advocated it via the â€œinteraction designâ€ point of view. ”
20 Sep 2009 at 09:02
A general observation from Scalzi,
The Internet does seem to be full of people whose knowledge of complex concepts appears limited to a dictionary definition.