Perception test

While researching a little this night (read: surfing Youtube clips to kill half an hour) I found myself watching this video:

http://www.youtube.com/watch?v=WSgE-7mP6Sk

Considering my post from yesterday about the art of testing nonfunctional requirements: We should first thing tomorrow stop asking people in the business "Does this piece of software work?" because they will look at the things they can see and filter out what they can't see! Damn..... We might just have to ask differently: "Did we miss out anything on this page?" and if the theory is correct they would be filtering away all the visible stuff and focusing their mind on what should be working but isn't....

Interesting thought, I think :o)

Regards K.

Testing for what you can't see

So - we delivered a product by the end of last sprint. October 1. was the deadline and we made it fine. Or to be precise: The code that we delivered worked fine. Nothing crashed, for instance. Well - was the release succesful? Not exactly...

It turned out that when we put code up to our staging environment we didn't have much of a plan for saying: "What does it mean to put something onto our staging environment?" We have always focused on being able to automate our releases so a release to our staging server never takes more than a few minutes and can be performed by anyone who has the password to our buildserver. In other words: Our Continuous Integration setup rocks - but what is it all worth if nontechnical errors are not caught until somebody is actually starting to USE our code? When is a feature Done - how do we test and assert that Done is really Done?

I will for the rest of my life never let nontechnical requirements to a feature be part of what IT can be blamed for if something gets released and doesn't work the way it was intended. That's just not what we are hired to do as software engineers - we build software. We are not supposed to have the deep insight in a business domain because we are hired to express the business needs towards their domain in programs and websites which provide the business with solutions to their problems. However - that's a dreamworld scenario because in a lot of companies IT has become the knowledge base of your business domain because of the insight you get into a domain when it is mapped to code. You have become bloated with too much information. How many of you have tried this - hands up everyone. I have both mine up right now ;o)

What usually happens is that the person implementing software also begins to take excessive responsibility for the business domain and while being responsible is good, being overly responsible is bad because people tend to think that "That's not our problem - that's something for the IT guys. They know what to do". When the business starts to react like this is the sound of an emergencyalarm going off.

I have a feeling that this is the usual case in most small companies and in quite a few large ones as well. IT knows what to do and how things are supposed to work. When this happens IT becomes responsible for the business domain and suddenly you have the business coming to the developers to ask for insight into their own domain.

I have a feeling that when we in collaboration with the business were unable to catch that a number of non-functional requirement caught us off-guard a few days before October 1. it is due to a number of reasons

• IT departement is supervising the business domain - but developers can't test their own code. Developers are in my opinion the lousiest testers the world will ever see - and that goes for both technical and nontechnical requirements.
• The IT guys takes the majority of responsibility because they know the business domain best - there can be a number of reasons for this (business culture for instance) but the business should never be excused for not being Master Jedi in their own domain and for not knowing their own domain at least as good as the developers.
  
• We tested what we could see - nobody tested for the things that wasn't visible.
  

What are your experiences in this matter? How do you lay off responsibility to the business domain experts and convince them that they are truly experts in their field and should take that responsibility on them? What are your Def. of Done criterias for completing a story? Lots of question asked, I know - drop a comment if you have something to share with me :o)

Regards K.

Microsoft Visual Studio 2010 sneek-peak

Microsoft is working on the next version of Visual Studio and has just published an article about the features of this and the corresponding version of .NET Framework which will be released as version 4.0.

 

I read the article and haven't dug deep into anything but I have noted that Microsoft claims that they will support Agile enviroments more in this release. So - with this in mind I read the article and this is what I noted down while reading:

• They have forgotten about the fiasco of CASE-tools and invented an Architecture Explorer which can draw visual diagrams of existing codebases. Visual diagrams of class coupling can probably sell the 2010 release to CEO's but is useless as a tool for developers. Typical example of some Microsoft gadget covered in visual sugar which might taste nice but leaves you with nothing but an empty stomach after you have eaten it.
• I noted this sentence: "Identify and run only the tests impacted by a code change easily with the new Test Impact View."  I (choose to) read it this way: You write a line of code and only run the tests impacted by your change. All other tests are NOT run. That's NOT very agile - early feedback is a core asset during agile development which is why you always run the entire testsuite in your project before each checkin. This tool is a good example of a tool which will do more harm than good in your daily life as a developer and I regret the fact that it probably will be the default to have this feature enabled after a standard installation of the 2010 release.
• The current Developer Edition and Database Edition is merged into one - that is actually good because agile teams don't distinguish between DBA-work and code. Everything is code and nobody owns parts of the business domain - so having the working environment being able to gap over both UI, code and database as default is a step forward.

I found an article on www.cio.com which goes more in-depth with the issue if you are interested. It is coloured in the sense that it doesn't question anything so read it to get to know more about the features.

 

I'm not very surprised by Microsoft going in this direction - doing a lot of effort to integrate their idea of what Application Lifecycle Management should be like but very little room for improvement and extensions to their way of doing things. If I had to work with someone who patented the idea of what software development was all about in our team and didn't leave room for me to challenge and change things - working with him or her wouldn't be fun. It could be and sometimes it probably would be - but the overall feeling would be mediocre at best. Why is Firefox the best browser out there? Because it allows you to extend it's basic functionality with something you find better. The way you are supposed to use the Internet isn't limited to what Firefix can and can't do - you own your own experience of browsing webpages through Firefox. If only Microsoft could get that and use it in their products...

 

Regards K.

 

P.S. - Not everyone at Microsoft is looking at their own bellybutton all the time. It looks like they will integrate jQuery into the ASP MVC, the Ajax Toolkit etc. which is very good news since jQuery is an opensource product which will continue to evolve in it's own direction regardless of what Microsoft comes up with in the future    :o)

JAOO 2009 - I'm going :o)

I have just returned from JAOO 2008 in Aarhus and that was all I hoped for. I can tell on and on about all the inspiration you get by going to such a conference but I won't right now. It might pop up on this blog in the months to come.

One of the things that settled in my mind was the fact that architecture isn't about structure - it is all about roles and responsibilities. Class diagrams aren't architecture - they are just a representation of one way to implement a given architecture. I don't know how many times I've drawn squares on a board to boxes representing "Person" and "Order" and by drawing a line between the two I believed I had the beginning of an architecture sketched. I couldn't have been more wrong and after these three days I'm beginning to understand why. Now I learned that in an architecture:

• Roles needs to be defined
• Responsibilities needs to be described
• Represent objects and actors to act on the roles and responsibilities you figure out

No wonder I repeatedly hit my head against the wall when trying to abstract my "architecture" a little, because building abstractions on top of implementations which have been built without a larger picture in mind is next to impossible. Programmers aren't used to describe intent which basicly is what an architecture is in itself - we just build stuff that works. I didn't get that one until this week.

I came to think of one approach I tried a year ago when modelling a new domain for an auction site: Object Modelling in Colour. Object Modelling in Colour essentially describes 4 types of objects, Party-Place-Thing, Moment-Interval, Role and Description. Using these four types of objects you can model an entire domain using archetypes to describe responsibilities and because each archetype is coloured you are able to quickly inspect a domain or describe a given domain to a non-technical person. We used it to model a new domain and the original domain model actually survived throughout the entire project so the initial approach made us deliver a very decent first shot at describing our new business domain. Just about everything else from there went horribly wrong on all levels but that's another story. Buy me a beer some day and I'll tell you all about it ;o)

Maybe this approach could be used again to model architecture? I haven't read up on it or heard from Modeling in Colour since then so the concept might have evolved since last time I used it but it could prove to be worth a try the next time we face an architectual challenge which requires us to take a helicopterride to get a birds-eye view on the things we work on.

One of the best quotes I heard during these three last days is this: "All code is cost. Only some code has value". Everything you do you should do only to deliver code that has value once delivered. You should focus on writing code that not only you care about. Sounds easy, right? It isn't...

I'll stop for now - I have numerous notes that I have reworked tonight. I am sure I will get back to reading them more often than previous ones because they are really good, I think, after reading them again during refinement and rework.

Regards K.

JAOO Aarhus - I'm going there Monday to Wednesday

I'm going to the JAOO conference in Aarhus Monday to Wednesday - I'm really looking forward to going there. I'm reading through the program right now - there are several tracks you can follow, i.e. Cloud Computing, Enterprise 2.0, Programming Languages, Railing, Solution Track and The Odd Track.

The conference is called "JAOO Conference - for developers by developers" - I looked up Microsoft TechEd and expected to find some similar subtitle and TechEd is mainly for developers as I can see it - developing Microsoft products of course. I would love one day to attend TechEd but I have this odd feeling that it is more of a commercial event where you get a pair of baggy 10$ sandcoloured pants, a pair of ugly glasses, a blue shirt plus a Beatles-haircut and suddenly you have 15.000 Bill Gates-look-a-likes wandering around praising a single technology. Maybe it is just a good, ol' prejustice and I would love if I was wrong about this one... Which is one of the reasons it could be fun to attend TechEd just to be able to go home and tell other people with similar prejustices that they should go as well.

JAOO markets themselves as being an agile conference and the technologies and methodologies presented on the tracks are more Java and Ruby-ish than they are Microsoft. JAOO does however have presentations where you get an insight into the .NET Technology and they are also able to invite a Microsoft stars such as Anders Hejlsberg and Eric Meijer to come and tell a story or two about LINQ.

The hosts and presenters of the tracks are not the primary ressource I believe - it is the people attending who will make the conference to whatever it will look like in retrospective. I am looking forward to sit down, get to learn new stuff and perhaps talk to people about agile stuff and what each of us are working on. If you are going (what are the odds? But anyway...) drop a note and tell me what you think and what you were able to take with you :o)

www.scrumalliance.org

I came by yesterday because I was awarded a membership as part of my Certified Scrum Training and accidently stumbled across the Email with my user credentials provided after the SCRUM course. The website seems to have quite a few interesting articles - and did you know that in order to be a Certified Scrum Trainer you must pay a one-time fee of nothing less than 7400 dollars... Of course you will have to pay an annual renewal fee of 7500 dollars but then your annual membership of the website is included (a mere 100 bucks).

I don't know - I just think that's a lot of money for having a reference to somebody who have an idea that you know something about Scrum. Anyway - I think I want to check out the site and read some of the articles. More to come later - if you know of other Scrum communities worth checking out please let me know  :o)

/ K.

Define user satisfaction

Quote from Software facts and Fallacies by Robert L. Glass - page 133:

"A user will be satisfied if he gets a product that meets needs, is available at an appropriate time, doesn't cost a fortune and is of reasonable quality".

We had a couple of real world users testing the website that we have been building for the past 3-4 months. I noticed a few things walking around yesterday evening while they were testing:

• Nothing crashed. I never had users come in to test any of my code on an entirely new website without anything crashing with an ugly ASP.NET stacktrace showing up.
• Nobody gave up and needed a lot of guidance help to complete their testing. There were a lot of questions of course and quite a few logical errors but people seemed to have a basic understanding of what they were supposed to do to keep moving forward.
• 4 out of 5 questions could be solved with a textual changes / graphics instead of written text or layouting the page a little differently. We could really use a dedicated tester which knows something about design and usability in our team.
• Nothing is as painful and as to see users revealing stupid logical errors. In Denmark we usually write the zipcode and the city on the same line: "7100 Vejle". We had an inputfield, some 30 characters allowed but we had clientside validation which threw an error if you entered any non-numeric value or more than 4 characters (all zipcodes in this country consists of max. 4 numeric characters. Small country, you know...). During our own day-to-day testing during development we had always just entered the 4 numeric characters which would pass validation check - and we would gladly have put this in production if users hadn't pointed out our own stupidity to us in advance.

As the wise men say: "You learn the most by your biggest mistakes". Point taken - we had a few things to correct. And - given the quote from above: We actually delivered something the users testing our system felt was useful - we tested on the night scheduled a month ago - we haven't spent more than a few months developing and it provided a solution to our Product Owners problem. How about that? :o)

Regards K.