It’s not the lesson – it’s the learning

It is not the GOTO talk on “Embedded Systems – Embodied Agents, Robot Programming in Java for the LEGO NXT Mindstorms” or the LEGO Lab, University of Aarhus class that’s important. Neither is the GOTO talk “What is Value” important in it self – the key lesson is in what you learn and bring home.

The students in the LEGO lab (at my alma mater 🙂 will try out the LEGO Mindstorms NXT series to learn about robots. First the industrial ones, that have a deterministic program, secondly about self-controlling agents. Compare it to the difference between an industrial robot in and assembly line – and a toy seal for psychological care treatments for trauma patients: One is sequenced and in a known environment , and the other reactive and don’t know the environment in advance. Reminds me of routinized and bespoke activities,  Testing AND Checking left and right side of the brainComputer Science students in this course struggle to control the robot environment, but quickly learn that the real world is not ideal. They have to test and experiment, calibrate and think outside the LEGO box.

Similarly JEZ HUMBLE, talked about “What is value?“. A huge whiteboard of prioritized and estimated SCRUM tasks is not customer value in itself – it’s a tool to discuss the value for the client/Product Owner/Sponser/ the-guy-paying-for-it. Awesome is value. To get awesome – set a business model hypothesis and test it. Make the smallest viable product (When “minimal viable product” doesn’t work, the story of apple). But remember they are people too – even oracles can be wrong, and set up a measurement that will be counterproductive. Management only focus on “cost” because it’s easier to measure – test the business idea and what you care about: delivering valuable software solutions.

It’s not the talk, it’s the learning.

It’s not the CS class, it’s the experience.

It’s not the test, it’s the idea.

See also: , dealing with uncertainty

 

[Disclaimer: I had press access to GOTO-Arhus2012 on behalf on GOTOCON]

GOTO for your development

GOTO Aarhus is the place for the new tricks in town:

Gilad Bracha and Lars Bak announced Dart in Aarhus, Denmark about a year ago as a “new programming language for structured web programming”. Yesterday, Anders Hejlsberg, once again in Aarhus, Denmark, announced Microsoft’s new programming language, TypeScript, “a language for application-scale JavaScript development”. Obviously, there’s something about the water in Aarhus that causes language designers to want to tackle the problem of large scale web development.

http://news.dartlang.org/2012/10/the-dart-team-welcomes-typescript.html ]

Now GOTO is not for script-kiddies or #programming for dummies” – it is applied computer science. Formerly the original name was JAOO being “Java Object Oriented” – but now the topics are more various, but still cutting edge. TypeScript has made headlines in both http://arstechnica.com and http://www.readwriteweb.com.

See also:

[Disclaimer: I had press access to GOTO-Arhus2012 on behalf on GOTOCON]

Boost your competence

If all you know is testing ABC systems at XYZ, you have a problem. It’s much better that you position your self as doing services.

Services is packaging, but important to understand moving on it the networked world. Get ready to deliver services – and view your competencies as such. Currently you work doing something (testing) within a domain at a company. Try to look outside the specifics of the current company and systems.

  • Billing, Rating, Credit card payments, Subscriptions in the energy domain
  • Order fulfillment in the telecom domain
  • Property trading in the public domain
Addressing services and generic competencies is what all the big players do – because, even if it does drive skills as commodity. It’s an approach towards what you can (sell). The real deal and innovation is to find, what mix of skills that make you unique – and not be just any other standard (tester).

Would you hire ‘you’? Or would you hire someone completely different from you?

Now…when I say to think about this question, I mean really think about it. Heck…if you have the time, sit down and work through the actual job description of what you think your job *should*be and who the person doing *that* job should be.

Don’t friend all the people next to you or join plenty of groups on LinkedIn

The trick is for connecting to connect primarily outside your usual crowd, nuture the weaker ties – those in the fringes of your network. They will bring more diversity into your network. If you are in a crowd being laid off, friending all in the crowd will not get you far outside the crowd.

Unfortunately the groups in LinkedIn have varying degrees of success, mostly very little. If there is an real active group that you fancy, join it if you want to for sure. But adding 10+ is beyond normal reach, I would think – do this bloke really have time to participate all them? More and more LI/FB groups are getting filled with new-bee questions and lucky-riders, not really a place for experienced professionals. Joining groups (also the FB ones) are like self-applied badges, it’s easy to get one but hard to know if it’s earnest. One would seem too insincere, many bloatware – and there’s really no way of getting the number right.

Do what you say – say what you do

You can get as much overboard in metrics and processes for agile – as in metrics and processes for waterfall projects. Business context demands it’s share of the delivery culture, but don’t confuse being agile with being unstructured – or with waterfall being overly structured. If you do what you say – and say what you do, you are more trustworthy both as organization, team and as person. Hot air, slide-ware and good intentions will quickly be seen through (and you might not even notice…).

[ What Metrics Do You Use in Agile? | FEBRUARY 23, 2012 |  ]

First, I only use metrics to get a 50,000 foot view on what’s going on.
Second, I do not use metrics to compare teams or individuals.
Third, I am much more focused on qualitative than quantitative measures.

Babies 0: Bathwater 1 |  December 28, 2011 | Iain McCowatt, Exploring Uncertainty ]

The common denominator is not the label, it is the team dynamics

Process and documentation can at least provide some base level of information sharing. Rip these out without replacing them with people talking to one another and the baby has gone out with the bathwater. Regardless of methodology and other labels: effective sharing of information helps teams to succeed. Whatever your methodological preferences, please look after your babies.

See also Tracking your testing progress and 4 Reasons Why Culture Is More Important than Strategy

The dog ate my homework
Homework Evidence by GlenNZ

http://www.threadless.com/product/690/Homework_Evidence/tab,guys/style,shirt

What do testers do on an Agile team?

You don’t need Testers – Or do you? | Thursday, April 19, 2012 |  ]

It doesn’t matter how you are working, what method you follow – Agile or Waterfall doesn’t change the need for testers. If you’re moving fast and light, testers need to adapt to the pace and to the way that they get and share information. That’s ok. Good testers can do that.

I hope that the testers will find any important or obvious bugs before customers do.

Without testers, not only do you put out code that you shouldn’t with bugs that you should have caught – you also lose a lot of important information about how good your software really is and what you need to do to make it better. If you care about building good software, this is an opportunity that you cannot pass up.

(my bold) see also The core purpose of softwaretestingAgile Testing Quadrants Explained