I ticked the wrong box

Arrrrgggg!

When I ordered my MacBook Air the only options I had for keyboard were UK English, and French. No US English when ordering from the UK store you see. So, I was trying to hack around with rcov today, and needed to alter some source. I wanted to copy and edit a line of code, preserving the original. To do this, I was just going to hash out the line, and put my altered line below. That’s where I encountered my issue.

THE UK KEYBOARD LAYOUT HAS NO # SYMBOL PRINTED ON IT!!!!

Luckily I found this page - Hat tip to QuiteTall.

ALT-3 for people who can’t be bothered clicking thru.

I mean come on - the keyboard has symbols such as § and ±, but no #?!?!?!? What’s going on with that?

For those of you unfamiliar with the term… Meritocracy.

Coté from Redmonk quoted the title of this entry in episode 14 of Redmonk Radio. Again, it’s another quote that was like an “Oh yeah” moment for me. In companies where you produce software (usually) the project timeline or budget is king. In the open source movement, the best ideas take as long to get implemented as needed - there is no overriding time line that says you must ship that feature by this date. Also, in distributed projects there can be healthy debate about the best way to implement things - the ideas and implementations with the best merit win.

I’m slowly catching up on these podcasts - making time on the train to listen is really working out for me.

Large software vendors do (often in the long term) listen and act on what their customers say they want. However, implementations are still missing the point. What customers say they want and what they actually want can be very different things.

Historically people (like me) in enterprises have harped on to vendors for years about how we want their large enterprise applications to be more configuration driven rather than coding driven. The actual purpose behind this was about time to market, resource availability with the necessary skill sets required to maintain and alter the application, effort around testing and deployment, and certainty about the validity of the syntax and sensibility of the customisation. Vendors have responded by closing the code base, but offering more complex configuration environments - which is exactly what we have asked for (see next paragraph about how we have asked for the changes). However, what they have provided doesn’t meet the actual business goals of the request. For example, I’ve been recently looking at some Product Configuration software that has a guided Java coding environment for rules definition. This doesn’t actually make the implementation simpler. It means that your (previously) relatively unskilled (and that’s flame bait if ever I’ve seen it) configuration staff have to significantly increase their skills to match those of java developers. Its called “configuration” because its done in a “configuration” tool. The configuration tool is as much a config tool as Eclipse is (which has code completion BTW, is equally applicable for the task, probably nicer to use and definitely cheaper). What it’s done is moved the effort from the development staff, to the configuration staff. Assuming staff are happy with what they do, developers are unlikely to want to join a “configuration” team, and configurators are unlikely to want to gain development skills. One may also argue that your testing and deployment efforts are more difficult, because the coding that was done by people who know how to code, is now done by people who don’t know how to code - this in my mind introduces more risk. You also don’t know which parts of the application are affected by this complex configuration activity, and this may drive for more rather than less regression testing.

I’ve also been reading recently about user stories, which are something I’ve never professionally come across. I’ve been working for my entire professional career on waterfall based implementation projects, with requirements and scope specified in documentation like traditional UML use cases, interaction/sequence diagrams, and IEEE 830 style requirements. I wonder if the large enterprise is its own worst enemy when it comes to vendor software direction and influence. We are always writing (and that’s the first mistake) very specific (and that’s the second mistake) requirements for vendors to implement, and influencing them through RFIs and RFPs which contain hundreds or thousands of these requirements. Maybe if the interaction was more conversation and (business) outcome based we’d actually get what we wanted, instead of getting what we write down - which is always going to be flawed (inaccurate, incomplete, technology based rather than business value based, and driving misunderstandings between reader and writer). Conversations about outcomes are the way to get around the limitations of written software system specifications.

What we actually want and what we get are often different things. I’m beginning to understand that outcome driven conversations between parties playing their specific roles are the way to go. In a supplier-customer relationship, the customer should tell the supplier what they want to achieve (in a business context), perhaps explaining why the current implementation does not meet their needs. The suppliers role is to understand the customers issues and the drivers behind why those issues are actually issues, and then propose ways those issues could be resolved. Often it may be a process or simple usability issue, sometimes there are fundamental issues with the implementation that require longer term efforts to fix. Regardless, the vendors know their software and the capabilities it possesses and the customers know their business drivers and understand how they are using the software. Each party should focus on playing their part in the relationship and achieving their eventual outcome (customer = achieving the business value and business purpose they want, and vendor = getting a satisfied customer, which hopefully translates into a big purchase order for them).

That’s some strong language there Dr. Drummond.

http://googleblog.blogspot.com/2008/02/yahoo-and-future-of-internet.html

While I am in favour of openness on the internet, I am also against protectionist measures (like enforced competition). I like the idea that if a company has the resources, they can buy another company. It is an idea that promotes liberty. Of course, in a situation like this it appears that openness may be at risk because of the duopoly that will (effectively) be created here. So, what has more weight? Liberty for the corporation, or openness and competition on the internet?

On this one, I’d be in favour of the openness and competition. The 3rd large player in this space does promote more competition, as well as another set of “standards” - IM protocols, interfaces/APIs for services, etc. I also like uk.finance.yahoo.com’s streaming stock price service, and it would be a shame if that went the way of the Dodo.

I also don’t agree with Microsoft’s historical handling of anti-trust situations, and I see that this will happen again in the future. They seem to be a more litigious organisation than an innovative one, and purchasing the competition only stifles innovation. Buying complimentary services can help growth, but competing services? No way.

I think in the long term this deal would be a bad one for the (concept of the) internet. But the offer price is very compelling. Who knows what will happen…