Improving Wetware

Because technology is never the issue

Sometimes I forget that I like Ruby

Posted by Pete McBreen 12 Mar 2007 at 12:25

Had a fun experience today

irb(main):001:0> 7.7
=> 7.7
irb(main):002:0> 7.8
=> 7.8
irb(main):003:0> 7.7-7.8
=> -0.0999999999999996

Yes I know it is a Float, but everything else just works so I was lulled into a false sense of security, after all the other two bits worked OK

irb(main):006:0> 7.7 + 0.1
=> 7.8
irb(main):007:0> 7.8 - 0.1
=> 7.7

But that 7.8 - 7.7 just did not want to play nice.

Backup script for typo blogs

Posted by Pete McBreen 14 Feb 2007 at 08:42

Ruby script for backing up blogs is here. Feedback from testers is appreciated.

Your blog is saved into a YAML file and can either be uploaded back to the original blog or a different one.

Backup or Restore the content of a blog to/from YAML whose host server supports the MetaWebLog API. (Currently supports typo|wordpress|blogger)

Script was originally created by Derek Mahar for migrating posts between blogs and then changed extensively to serve as a backup/restore utility by Pete McBreen

Sample command lines (program prompts for blog password)

ruby backup\_blog.rb username backup.yaml 25 typo backup

ruby backup\_blog.rb username backup.yaml num\_posts typo restore

(the num_posts argument is unused on restore)

Note: typo has bug whereby it ignores createdDate when creating URL, but does show correctly posted x days ago. Clicking on the link on the home page fails but it generates feed OK — puzzling — not fixed yet.

Code uses the metaweblog API

source_posts =

and then saves the posts to a YAML file

f =, "w")
f.puts source_posts.to_yaml

Tools are interesting, important, and irrelevant

Posted by Pete McBreen 08 Feb 2007 at 12:52

My interview for the Sticky Toolkit with Joey McAllister is now online.

The best question was when I was asked about changes I have seen in development over the past few years. This was mainly because One change I have seen for the worse is the habit of producing ravioli documentation… [that just repeats] what the parameters to the method are and what it returns.

Doesn't everyone think about testing like this?

Posted by Pete McBreen 04 Feb 2007 at 02:05

Michael Bolton recently pointed out on an agile testing list that few people think of
Testing as questioning the product in order to evaluate it or Testing as an empirical, technical investigation of the product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.

This is interesting to me because the Testing as finding defects is not very high value and test driven development is a technique to allow developers to think through issues, rather than something that protects the stakeholders interests.

Yes Testing-as-design and Testing-as-confirmation are interesting, but they are not typically the things that make or break a project.

Professionalism and Engineering

Posted by Pete McBreen 19 Jan 2007 at 02:46

Been thinking about how craftsmanship interacts with professionalism and engineering. Real engineers seem to have professionalism sorted, in that they have personal accountability and responisibility for their work.

Software developers do not have that yet because we know that our stuff may/will crash. Indeed most software licences state that there is no guaranteee that the sofwtare will even work.

Reality vs. Theory

Posted by Pete McBreen 14 Jan 2007 at 10:58

In software development, the reality about what is happeing often disagrees with theory as Michael Riddle points out.

Philosophy of Testing

Posted by Pete McBreen 22 Dec 2006 at 11:44

A really great article by by James Bach Philosophers of Testing that explains how philosophy is closely related to the art of testing.

The quote at the end really sums it up That’s how I became a philosopher: My father believes that I must think for myself, and I always agree with my father.

A classic quote

Posted by Pete McBreen 08 Dec 2006 at 11:27

The Bjarne Stroustrup interview continues with a great quote.

The idea of programming as a semiskilled task, practiced by people with a few months’ training, is dangerous. I couldn’t agree more.

Bjarne goes on to say We wouldn’t tolerate plumbers or accountants that poorly educated. We don’t have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.

In praise of C++

Posted by Pete McBreen 02 Dec 2006 at 07:29

Saw a good interview of Bjarne Stroustrup recently, including a wonderful soundbite There are just two kinds of languages: the ones everybody complains about and the ones nobody uses.

Bjarne made a great understaement the average Bell Labs programmer was significantly more able than most people’s notion of an “average programmer.” Well that could explain why C++ is expert friendly.

But on that point Bjarne is clear that C++ has indeed become too “expert friendly” at a time where the degree of effective formal education of the average software developer has declined. However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts.

I disagree that more formal education is needed, but we do need to develop more expertise in software development. Personally I have used C++ a lot in the past and was always impressed by the systems that we built using it.

Everyday Scripting in Ruby

Posted by Pete McBreen 30 Nov 2006 at 10:47

Brian Marick has finally finished his scripting for testers book now called Everyday Scripting in Ruby. A part of the Pragmatic Bookshelf the book should be a great introduction to the art of scripting tasks to avoid drudgery ;-)

Does SOX solve the problem?

Posted by Pete McBreen 23 Nov 2006 at 10:45

It is interesting to see that there are starting to be articles critical of SOX. Yes, there were issues to be addressed, but putting a massive layer of beaurocracy on top of already stressed corporations was possibly not the best option.

Wading through code

Posted by Pete McBreen 18 Nov 2006 at 10:39

There are no shortcuts to becoming a better developer as Uncle Bob talks about in Wading Through Code. Like it or not, becoming a good developer requires a lot of work.

Agile requires discipline

Posted by Pete McBreen 12 Oct 2006 at 11:50

Brian Marick shares his thoughts about the value of clean code. He supports the idea that the Agile approches require a lot of discipline Agile depends critically on programmers keeping the code clean.

What evidence do we have that Agile works?

Posted by Pete McBreen 10 Oct 2006 at 11:51

Steve Yegge has some good questions about how good is Agile development and how do we know for sure about how good it is. He sees quite a lot of religion in the Agile approaches, something I noticed a lot of while writing Questioning Extreme Programming.

To date we have not done any really good experiments to validate whether the claims of the Agile approaches are credible, sure we have lots of anecdotes, but no evidence either way.

An interesting design failure

Posted by Pete McBreen 09 Oct 2006 at 12:48

Bruce Schneier poinmted to an interesting failure mode for ATMs. Given that the ATM is a case study in the Use Case Course this is one failure mode we did not consider.

  • The man then punched a series of numbers on the machine’s keypad, breaking the security code. The ATM was programmed to disburse $20 bills. The man reprogrammed the machine so it recorded each $20 bill as a $5 debit to his account.

It seems thatthere is a default password to allow the installers to program the machines.

I thought by now we would have learned NOT to have default passwords on systems.

Guess my answer to this

Posted by Pete McBreen 08 Oct 2006 at 11:55

Over on Coding Horror, Jeff Atwood asked Is Software Development Like Manufacturing?

Remembering the users

Posted by Pete McBreen 07 Oct 2006 at 09:05

A great article by Kathy Sierra about how easy corporations of all sizes focus on internal stuff and forget to make sure that their users are getting great software.

Can "Thought Leaders" change their mind?

Posted by Pete McBreen 05 Oct 2006 at 13:13

This was prompted by a comment from Dave Rogers, reminding me that I have been away from writing for too long. After reading he article I was prompted to think about the circumstances under which someone who is recognized as a leader in the field of software development could change their mind about something…

The way IT is set up, there is a real penalty for realizing that you want to change, but at the same time the technology is changing so fast that we all need to change. Hence the leading Java gurus are unlikely to become the leading .Nyet gurus, even though for most practical putposes Java is indistinguishable from .Nyet.

Seen a Computer Operator recently?

Posted by Pete McBreen 23 Aug 2006 at 14:32

Not sure where I read it, but in one of the many blogs about the 25th anniversary of the IBM PC, someone was talking about not seeing computer operators any more.

Kind of puzzling that, because although most sites no longer have anyone with a title of Computer Operator, there sure are a lot of System Administrators around. The daily tasks they might be doing are subtly different, but the basic goal of what the System Administrators do is basically the same as that of the Computer Operators, keep the machines running, back up the data and do system upgrades.

Requirements can look different when presented under a different role name, but the only difference may be in the details of the technology. At the summary level the goals are the same, we still need someone to look after the machines so the real users can get on with handling their day jobs.

Requirements - Documentation, Conversation or Invention?

Posted by Pete McBreen 12 Aug 2006 at 04:25

Over the past 30+ years, the way we investigate, analyze, capture and communicate requirements has changed at a much slower rate than the way we do the rest of software development. Use cases shifted things a bit and the more recent user stories have had some impact, but while the productivity of design and development activities have improved dramatically over the last 30 years, comparatively, requirements activities are still stuck in the quill pen era.

Improving requirements activities means adopting different ideas about what it means to investigate requirements, to reappraise what it means to communicate requirements and to fundamentally rethink the role of requirements in software development projects.

Being aware of the distinction between explicit and implicit constraints helps, but it is not enough.

  • Some requirements can just be documented, they are well known and understood (the explicit constraints)
  • Some requirements emerge as part of conversations (the implicit constraints)
  • Some requirements do not really exit yet, they have to be invented