Unit Testing

This statement from http://www.joelonsoftware.com/items/2004/12/06.html irritated me:

However, a good, experienced developer is about 100 times less likely to write bugs that will be uncovered during unit
tests than a beginner. It is therefore practically useless for the former to write these... but most methodologies would
enforce that he has to, or else you don't pass some phase.

Unit tests serve to measure compliance of code with the developers understanding of the requirements and crucially, control project velocity. If defects from unit tests rise then dev time is spent fixing the code, slowing dev down to a pace where an appropriate degree of compliance is achieved.

If you are very experienced and write largely defect free code you may travel fast and light - turning the unit testing dial down to 3 - maybe only testing the really hard stuff. If you are less experienced or generate defects then you may want to turn that dial up to 7. The problem occurs when you cannot guarantee that the code written will always be updated by the same person, or a person with the same defect introduction profile[1]. In this case you may end up with the dial at the wrong setting, defects are introduced and worse, development isn't slowed to a point where the defects stop appearing in the main code base. Of course, you may have tactical additions that don't have the same quality bar as the rest of the code and you maybe able to turn the dial right down, but that's different as a quality bar applies across the team and not to individuals.

So, change the unit test dial for an individual at your peril, you never know when someone else may edit the code.

A wider problem with the statement is that it shows an atomistic approach whereas IT projects and development teams are complex systems and issues relating to those projects and teams need to be considered holistically as well.

[1] Since turning down the dial has to recognise the types of defects you are going to stop testing for.

Rhetoric in IT

http://www.joelonsoftware.com/items/2004/12/06.html

I loathe rhetoric, it all ends up so black and white, them and us.

> The trouble with MSF is that it starts with a group of successful developers, who
> are successful because they are resourceful, intelligent, experienced, well-
> meaning, and have plush private offices with doors that close, and then
> attempts to claim that if impose some of their "best practices" on your team of
> unskilled developers, you will achieve the same results. It's like Daniel Boulud
> selling a manual to McDonald's fry cooks. "Out of potatoes? Try Yams. Throw in
> a bit of rosemary. Toss and serve with a lime-basil aioli dipping sauce. Yum."
>It's just Best Practices, right?

I find little to substantiate the claim that MSF says the practices will allow a team of unskilled developers to deliver the same results as successful developers. It maybe that some people, seeing IT and people as a commodity, infer that a process can be applied to a production system irrespective of the people. However, I don't believe that MSF provides the data to support that view.

I would prefer critiques on method in general and in specifics to distinguish between:
a) What was intended and the context it was intended to be applied in.
b) How they are used.
c) The problems in the statements about a) that lead to problematic b)s.

Lo-fi prototyping & Viso

Some of you will know that I'm keen on using lo-fi prototyping, or at least the UI flow sketching part, to elicit requirements on user interfaces (static/dynamic aspects) and functionality.

Whilst practising this and trying to sell the technique into an existing project I came across the term wireframing, a term I'd not heard before withint this context. Wireframing refers to the practice of rendering a skeletal GUI and all its navigation paths in a sequence of diagram. This process assists in the process of gathering data, ui and functional requirements. Its relationship with lo-fi prototyping is that lo-fi includes wireframing, but in a lo-tech fashion, i.e. no Visio.

Some people believe you can use HTML to produce your wireframes. I'm not convinced. Wireframing is about diagraming something, preferably with a user. Feels like the most appropriate tool for diagramming would be a diagramming tool. One of the values of using HTML is that the navigation paths can be demonstrated. I imagine this could work for simple user interfaces but be hard to get right for complex ones. I also value being able to draw these diagrams whilst sitting with the user or business expert. I suspect having to diagram in a wysiwig HTML editor would just get in the way and reduce the interactivity.

All in all I prefer to use pencil and paper with a user and then, if really needed, translate that into an editable electronic representation.

Choice

"Choice"[1] is a mantra in western society, and everyone wants, is expected to, exercise choice. This is going to drive IT service organisations to provide more and more choice. Choice in risk, delivery model, function, timescales, cost etc.

[1] Choice being distinct from significant variety, knowledge or need.

Commoditised IT

IT practioners see themselves as specialists in an area that is hard. Outside the industry IT is seen more and more as a commodity. Alongside this commoditisation we see the rise of pervasive computing, more and more people connected to each other via smaller and smaller devices. Once something becomes pervasive you don't tend to pay attention to it.

This has to effect the industry. There is constant pressure on costs and raging debates about the benefits of a CIO in 'non-IT' businesses along with the dissoloution of IT departments in favour of outsourced teams (badged or otherwise). Why have in-house knowledge, it's a commodity - like buying a hair dryer.

So there is an opportunity - whilst there remains a difference between the perception of IT as a commodity and the actuality[1] there may be an increasing need for specialists who can unpick the mess generated from false impressions of ITs state.

[1] I am entirely unconvinced that IT as a whole exhibits the characteristics of a commodity.

Backward compatibility in XML

I wonder if XML messages should contain something like this (when straightforward backward compabiblity by flexible schema is not enough):

<version>
   <number>1.4</number>
   <transform to='1.3' version='0.1'>http://......14to13.xsl</transform>
   <transform to='1.2' version='0.4'>http://......14to12.xsl</transform>
   <transform to='1.1' version='0.3'>http://......14to11.xsl</transform>
   <transform to='1.0' version='0.5'>http://......14to10.xsl</transform>
</version>

so that if you get a message for which you can't process that version, you can
lookup a transform to map to a version you do understand. If there is no transform then its an incompatible version change.

You could even imagine the URL being to a web service to handle further reaching changes, though performance would not be great.

Requirements, analysts and language

When you look at new organisations to assist you in COTS based development one of the questions must be 'do they know your business?' and the other 'do they know your domain?'. If they have a product with a good fit then the answers to these questions will be obvious, where there are significant gaps then these questions become more important, or do they? If I'm in foriegn climes then I'll attempt to learn at least some basic of the language, and knowing that mispronunciation can create misunderstandings, will pay careful attention to meaning and pronunciation. When I'm in a country that speaks English I'm careless, assuming that my English is the same English as the reciever of my verbage. This assumption is broken, as anyone who visits the US finds out quickly. It's an assumption not made when trying to speak a foreign language.

I wonder if it is easier to engage with an organisation that doesn't know your domain, since they won't make subtle assumptions about your domain or your business simply because they *think* they know the language you are using.

Maybe 'preferred readings' are easier to construct if you don't speak the same language and don't share words that map to different social constructs.

That's an extreme view but it seems that at least you need to pay more attention to what someone says if *they* think they are speaking the same language as you.