God Object

We've had problems lately in our Domain Model - it just isn't very easy to test and maintain so I researched a bit on the subject and found myself reading about God Object... Guess what I realized? We haven't followed the very basic principles of good OO design so we've ended up with a 1200+ lines of code long single class with 50+ methods which is responsible for everything happening in the M in our MVP triangle for some 20+ user stories implemented... High cohesion? I think not. Low coupling? I think not.

I've read a little further and found www.antipatterns.com/briefing also to be very informative about antipatterns in OO development. Right now I've got the hots for NDepend - my idea is that we need some kind of continuous feedback on our design and NDepend can give you feedback about cyclomatic complexity, lines of codes in your classes, number of methods in classes, the dependencies and relationships between classes and assemblies etc. etc. - and NDepend reports can be fully integrated in CruiseControl.NET which already is a cornerstone in our daily development cycle. I don't think a fullscale report on every piece of our current , non-tested, 5 year old code will do us any good - I actually don't think I dare doing it at all ;o) - but in our new projects to come I think NDepend could help us by flashing a warning sign when and where software entropy begins in our software. This feedback will enable us to reevaluate our design based on reports on the current state of our code and hopefully we'll be able to see antipatterns emerge in our design sooner.

Regards Kristian

Signs of having a dysfunctional team - great article on www.scrumalliance.org

I just read a great article on www.scrumalliance.org about team dysfunction in a Scrum environment. It's the first article on www.scrumalliance.org I've read and I think it is high quality stuff.

"Agreement isn't the same as harmony" is a quote I came by a few months ago. I try to remember this every time we've had a heated argument within my own team because as long as we respect each others opinions disagreement isn't bad in itself. It can merely be a catalyst for a later team commitment to i.e. design changes.

You have to distinguish between disagreement and disharmony - and of course you will have to have experienced both on your own body to be able to know the differences between the two ;o)

/ K.

OO - how hard can it be to explain?

We have hired a new teammember who started yesterday - very good news since our UI skills lack a bit and this should be a lesser problem once our new co-worker is up to speed.

However - our new teammember is fresh out of school and haven't learned a lot of the core concepts which we (the rest of the team) use on an everyday basis and take for given that we all know at heart - so having to explain what a source control system is, what the difference between "=" and "==" is in C# and questions like "What is object orientation"... That was one of the questions I got and off I went to see what Wikipedia had to offer on the subject

The intro is quite nice but I stopped after a few pages because GoF patterns aren't what you should throw at somebody 15 minutes after being presented to the OO paradigm for the first time. So we talked a little and I said I would go find some tutorial which could explain the fundamentals of OO in a 1-1 manner.

And I searched. And searched. And tried another search. And finally, after having spent nearly one hour on Google I have given up. I am simply unable to find a single webpage which explains the fundamental concepts of OO with a reasonable amount of C# code used to make the abstract concepts just a little more concrete. I see myself as being quite good at finding the stuff I need on Google so this doesn't exactly boost my selfconfidence a lot... Sure there are a lot of tutorials and I managed to find what I was looking for on java.sun.com but the sourcecode provided is Java and concepts like "What is a package" doesn't make sense to a newbie in C#.

I regret to have given up (I blame Google of course for not providing me with the answer to my prayers) but I will give www.stackoverflow.com a try on this one. And I wonder how spoiled we have become because of Google - I actually got angry with myself for not being able to input the 3-4 simple keywords into Google which would reveal the webpage I was looking for. Searching for various combinations and phrasings of "oo", "object orientation", "msdn", "tutorial", "explained", "c#", "fundamentals" etc. etc. etc. didn't do the trick this time.

I remember once upon a time (pre-Google that is) where you remembered each and every time you managed to find something valuable on various searchengines - a time when Hotbot and AltaVista were my favourite amongst lots of searchengines. Such a long time ago - 5-6 years I believe... :o)

Regards K.

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.