You are currently browsing the category archive for the ‘software development’ 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
Back in 2001, traditional management had the idea that if everything was documented, things would work out fine.
via Innovation: Applying “Inspect & Adapt” To The Agile Manifesto – Forbes.
Three reasons to read this article:
- because in 2012 90% of management DO have the idea that full documentation means “it will work fine“
- because it’s an interesting article about agility and beyond (adding some lean startup concepts too)
- because most of the stuff that you read comes from Kent Beck and you should read everything from Kent. PERIOD.
Tell us what you think
PierG
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
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
When a SW project finish, a Project Manager is a happy, a company can send the bill and … the team moves to another project leaving the code to the lucky maintenance team.
Is the project team deeply motivated to build a product who can last for long? Is the maintenance team skilled (and willing and has the right incentive) to make the system working better and better?
Mmmm….
Here is a possible recipe:
Form long-lived teams around applications/products, or sets of features. Â A team works from a prioritised backlog of work that contains a mix of larger initiatives, minor enhancements, or BAU-style bug fixes and maintenance. Â Second-level support should be handled by people in the product team. Â Everyone in the team should work with common process and a clear understanding of technical design and business vision.
via Projects are evil and must be destroyed | Evan Bottcher.
What do you think?
PierG
I’ve collected some resources about “UX and friends” and I want to share them with you. I hope they can inspire or be helpful!
Usability Design Considerations for Web Forms
http://www.onextrapixel.com/2012/04/13/usability-design-considerations-for-web-forms/
The Death of the Wireframe? Towards An Integrated Approach to UX Design
http://www.fabernovel.com/en/blog/284-the-death-of-the-wireframe-towards-an-integrated-approach-to-ux-design
The New Google+ Is More Beautiful Than Facebook
http://www.fastcodesign.com/1669497/the-new-google-is-more-beautiful-than-facebook-but-it-doesn-t-matter
PierG
I’ve this tweet in my ‘favorites tweets’ list and I love to read once in a while:
What do you think?
PierG
software design problems have a few great answers, many flat out wrong ones, and lots of ways to improve any actual situation – K. Beck
PierG
“create a low-fi prototype at the first responsible moment, create the hi-fi product at the last responsible moment” @aslamkhn
via Twitter / @KentBeck: “create a low-fi prototype ….
PierG
Subscribe
PierG (aka Piergiorgio Grossi) 