You are currently browsing the category archive for the ‘IT’ category.
IT people is often scared when I say that I don’t like the traditional testing phase in IT projects.
I understand, it’s so relaxing to know that you have a bunch of people to blame when projects go the wrong way: “we did 3 month of testing, we really couldn’t do more to save this project!”.
And if it’s not the testing team, you can always blame the requirements team for gathering them badly. But this is another story, another post 
. Let’s get back to testing.
What I generally don’t like about testing is that you do some operations based on … what the system is designed to do. Someone writes a requirement, someone (else) writes one or more test cases to prove it, someone (else) writes some code and finally someone (else) reads the test case and uses the system giving his interpretation of the behavior … giving a GO/NO GO.
Should I explain why I feel uncomfortable? I hope not but let me add an unobvious thing: where is reality in this long chain? Who’s in charge of saying if the system is doing what is needed and not what someone (else) thinks it should be doing?
Scary, isn’t it?
PierG
We will talk about a new development technique called WDD or Worries Driven Development.
You might know another couple of *DD techniques: TDD and DDD but they are by far less powerful than WDD.
TDD or Test Driven Development has been invented by Ken Beck (@kentbeck). As Wikipedia states “is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards”.
DDD or Domain Drive Design is a little more recent, especially it’s hype, and as Wikipedia says “is an approach to develop software for complex needs by connecting the implementation to an evolving model.The premise of domain-driven design is the following: Placing the project’s primary focus on the core domain and domain logic; Basing complex designs on a model of the domain; Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.” In Italy Alberto Barndolini (@ziobrando) is really good at it!
WDD is more powerful because it works at a deeper level. It acts at the level of motivations. We tend to do what we do for one of two reasons: to seek pleasure or to avoid pain.
Now our culture tend to push us to the ‘avoid pain’ side so we tend to use it more often as a motivation to do what we do. So what’s more relieving than solving a problem to ‘avoid pain’?
That’s where WDD come from: we do what worries us. Or better we do, schedule, put in priority what can have consequences that can worry us.
So the algorithm is: if you don’t have it, create a problem, throw it in the future, communicate it so that everybody can be worried. Now you are ready to make a lot of overtime to solve it to ‘avoid pain’.
The secret? WDD is not that new: it is quite often used as a primary development paradigm in many offices of medium-big corporations. And it works …. maybe.
PierG
We have a practice at home: one day per week we have a ‘reading evening’. No TV is allowed: after dinner we take a book and we read all together.
Now what’s happening lately is that my 8-yrs-old digital-native heavy-iPad-user computer-enthusiast son started saying:
“OK Dad tonight we have our reading evening and you cannot read with the iPad, you have to use a paper book”
So I asked:
“why????”
And he said …. ok I don’t want to tell you the answer immediately .
You guess: why he doesn’t want me to read with the iPad?
PierG
I’ve heard, in different moments in time, different definitions of how an IT Manager, a CIO, should look like. Which are the most important skills, the background she has to have.
At the beginning, it was all about technology:
IT was too far from human beings
and IT was available only in big corporations. The IT Manager was the guy with the white coat: an expert of her matter. An IT guy.
Than IT became more commodity and it was the time of business:
IT was too far from the business
and IT decided it was time to talk the language of the business. So the IT dept moved under the CFO or the COO, and the IT Manager became a ‘business man’. Technical skills were no more important for her: there was the outsourcing and the SLAs to cope with the ‘technical stuff’.
Then the internet came, and Google, and Facebook, and Twitter … and all of the sudden
IT, inside corporations, is too far from real life
and people inside the company use to have such a bad IT experience that he would never accept at home … even for free.
To manage all of this we need a new race of IT Managers: they must have deep understanding of both parties. They must know a lot about IT and a lot about making business. But today it’s no more enough. Nowadays IT tech skills and management skills can be an obstacle, sooner or later, if they are not enriched with good design skills.
In the innovation and design era, to move IT at the right speed (maybe 10xFaster) and at the right level of innovation, IT + management + design have to be carefully used, melted, weighed out.
PierG
p.s. Thanks to my friend Nico Bigi for the inspiration of this post
The future of users manuals is … no user manuals.
And what is the future for most companies is present for companies like Google.
Here is what happened to me with the new version of GMail:
A single page, the first time I use it, manual ‘in place’: easy, clean … a great pattern to me.
PierG
Extremely interesting study by Google on the usage of smartphones, tablets, PCs … or better on the usage of ‘screens’: The New Multi-screen World.
Thanks to @HagakureLive to link the presentation in his tweet.
PierG
Do you agree?
+ operational advantages such as setting up infrastructure in minutes rather than months, completing massive computational projects with a large number of resources quickly, and scaling architecture up and down to provide the needed IT resources only when you need them, deliver targeted IT solutions fast for individual business units – these deliver a “return on agility.” The return on agility delivers business value by allowing you adapt rapidly, while remaining focused on your core competencies rather than distracted by operating IT infrastructure.
But more importantly it allows the business to change and dramatically reduce time-to-market for products. It drives down the cost of experimentation and allows companies to explore many more product directions with minimal risk. In the current economic climate where capital is scarce, being able to develop new products rapidly without the need for major capital investments is crucial to the success of businesses.
from Total Cost of Ownership and the Return on Agility – All Things Distributed.
PierG
Lately I’ve blogged about internal IT projects that do fail and one of the main reasons: lack of Product Owner (Why big projects fail in corporate IT).
Today let me emphasize another major reason: often the team who’s in charge of a project … will leave (I’d say run away as fast as light) as soon as the project is complete. And usually ‘complete’ means ‘when we are exhausted of fighting with the supplier for bugs, change requests and new features’. And all this means that the project is not complete at all. And in any case we know it will evolve.
What is stimulating the project team, in such a context, to work effectively? Work for simplicity? Work to establish a system that will grow up or change in the future weeks / months / years? Are they measured in any way on these goals? Or are they measured on ‘close this fuxxing project quickly that we have already spent all the money they gave us’?
PierG
Whatever happens, fewer and fewer IT departments will own their employees’ equipment. “The genie is out of the bottle”
via IBM Faces the Perils of “Bring Your Own Device” – Technology Review.
It’s tough, it’s dangerous and … it is inevitable.
IT Manager, CIOs out there, what are you doing on this topic? What do you think? Bring your own device or not?
PierG
p.s. Thanks to Davide for suggesting this article.
By By R/DV/RS, Some Rights Reserved
Every time I hear of a big IT projects, with a big RFP, with a big upfront multi-months/years analysis … I think of what happened to my friend Gianmarco some years ago.
He bought a house. The house was already partially built when he bought it (quite common in Italy). As soon as he bought it, he had some choices to make like: where do you want the light switch in the kitchen?
Yes because in the contract the constructor left some flexibility in the form of multiple choices on some things: in this way he can manage some of the changes the owner will need.
Now the problem is that Gianmarco wanted the light switch in a position and of a type that was not part of the options so … he had to pay an extra something (Change Request) and he did it ’cause it was his house, his dream.
As soon as he had time, so many things to do!!!, he went to the furniture maker who designed a great solution but … unfortunately they discovered the new position of the light switch was not good at all. Unfortunately the work to move the switch was already done and so some more money where need for another Change Request.
So two choices: have a ‘not such great solution’ or .. pay another something.
As it was his new house, Gianmarco decided to pay again.
That was a great period for Gianmarco as, few months before moving to the new house, his wife discovered to be pregnant! Great news!
The baby was born few weeks after they moved to the new house and quickly they discovered that this unexpected ‘event’ was not compatible with the brand new kitchen: there was no big table or proper position where to ‘sit’ him and have him under the watchful eye of his parents. So??? Another Change Request :)
Now, going back to my IT projects I have a question: why do we, as IT people, learn from the wrong examples?
PierG
Subscribe
