The day before the day

This is it - I'm leaving my office for the last time tomorrow. Yup - I have gotten myself a new gig at DGI (Danish site only) which is a non-profit sportsorganisation. They want to build up services and websites for their members which they can use to i.e. administer members, create tournament plans for competitions and other services which I haven't really got a clue about yet.

I'm leaving my current project with a sense of akwardness and sadness. We have been late for a long time delivering what we were supposed to deliver mainly because the scope of the project has changed and we have suffered from numerous of confrontations between team members, between team members and the house and between the house and the house... I think we have been like boiled frogs - we somehow grew accustomed to living in chaos all the time with changing directions and team members being frequently added ore replaced. We have lived in it for so long that we as a team didn't or at the end couldn't even manage to describe why we failed on deadline after deadline. Phew... The last thing I have heard on my way out of the door is that the ASP.Classic guys have estimated a solution which is based on the current ASP.Classic platform. The same platform that my project was intended to replace with a .NET solution. Do not get me wrong - I totally understand that the business HAS to take some sort of action and it is not plainly wrong to go with what you know when everything else have failed you. I am just not overly excited by having worked on a project for about three quarters of a year just to see everything being buried three days before I leave for another job. It sucks - big time.

I have learned a number of things which will be a big, red warning sign for me in future projects:

- If developing in an agile enviroment and the team fail to deliver running code after a sprint
- When the technical infrastructure for various reasons breaks down often enough to inflict progress
- No technical backlog at the beginning of the project
- No established estimation techniques of backlog stories from project kickoff
- No infrastructure established at kickoff (testing servers, QA servers)
- Lack of communication between projects
- Lack of communication within the project
- Lack of written documentation on completed issues

...plus a number of other issues I probably will be painfully aware of in the weeks to come.

I have a strong feeling that I can't save the world on my own by doing all these things the right way from day one in my new job so my main focus when I start on Friday at 9am is this: I will NOT accept that we fail to deliver running code at the end of future sprints. If - (I know - if and if and if) - if we had delivered something which could be deployed and tested by the business I am sure we would never have been in this situation. We might be somewhere else but 90% of all the issues we have discovered have been a combination of lacking communication on all levels and the fact that we never delivered anything. The business thought they knew what we were about to give them but they hadn't actually seen anything on the screen. We blew it totally on this one - and it has cost my to-be ex-employer quite a lot of money having us coding away on something which probably will never be used anyway.

"Success is something built on the top of all your failures" - damn, I am gonna be good at this some day ;o)

Regards K.

Test-Driven Development and the quality issue

There has been quite a lot of fuzz lately regarding Test Driven Development (TDD) - I have seen a number of posts where poeple are asking if the maturity of the tools on the market make old-school TDD obsolete. I have also seen posts where Ben Hughes asks if TDD really ensures quality.

That made me think about the term "quality" - what is software quality seen from a customer's point of view and how can we convince them that the software we produce are better than the one of our competitors?

I don't really think you can measure very much out of TDD in a sense of software quality seen from a customer's point of view. I mean - do you really care how Microsoft develops Windows XP and Windows Vista? I couldn't care less - neither do our customers as long as our sh** works every time. Even when our customers have a negative experience because they are unable to fulfill whatever task they were set to do because we as software engineers have failed to deliver - do they start to ask questions? Not really - they start looking for the products developed by our strategic competitors on the market to look for a replacement of the crap we have convinced them to install on their harddrive.

The principles and paradigms on which a software product has been built upon can and should never be a quality metric for our customers. They will never care anyway. TDD is just one (very useful) tool out of many when we develop software. In terms of quality it should only be a metric inhouse whether or not our software has a certain degree of code coverage for instance... We must not be mislead to believe as developers that anyone else but us really care what tools are in our toolbox!

Why do we not get fired when we deliver poor quality?

I have just read the following post: There is too much money to be made in software development and I started thinking... I have heard about painters who were fired for doing a lousy job. I have heard about carpenters, accountans and bar staff who have been fired for being lousy at their work. But after some 6 years in the software industry I haven't heard about _anyone_ involved in developing software who have been sacked merely for delivering low quality software... Why is this?

A: Are we as developers not able to define what's quality seen from a developer's perspective?
B: Do our superiours even know what we're doing - and hence does not know how to measure the quality of the software we produce?
C: Is this just proof to the fact that the users of our system do not care one bit and hence our superiours do not want to fire somebody on the basis that the quality of the software is poor - as long as the users are happy?

I don't know... What do you think?

Backup part 1

Lately I have moved every piece of data I treasure the most (images, documents etc) to a SubVersion repository to ease maintaining such as trivial backup procedures to a remote location. Things like these just turn out to be a lot easier when everything is gathered in the same location on your harddrive and when you get full revision history of all your Word documents as well - why haven't I done this years ago? Hmmm...

Anyway - I have bought an external harddrive on which I want to store a backup of my repository on a nightly basis. This way I will always be able to take with me the latest documents and images whenever I feel like it. I started whipping up a Robocopy of the repository but somewhere along the way it started saying "Out of disc space"... On a 250Gb harddrive that is.

A little debuggin revealed that I have never formatted the disc so it was delivered with a default FAT32 partition... This way files can never be larger than 4 GB and that really sucks when one of my Subversion revisions contained all my images which grossly exceeds that size... So as we speak I am moving everything away from the external drive (I have of course cluttered it with secondary things like audio, videos, loads of PSD's and other stuff which doesn't take up space AT ALL...) so I can reformat the drive to NTFS.

Lessons learned:

1. Check before you do anything that your source drive is NTFS (not so obvious but it should take you 5 seconds to check and verify that you don't get caught with one leg on each side of the creek).
2. Possibly you could add smaller portions of data - a 4GB revision is indeed a lot of data
3. Write PackardBell (the harddrive vendor) and ask the sales departement why the heck they are shipping stuff with ancient partitions? "Backward compatibility" - I know I know but at least put a large yellow sticker on the disc if you decide that you still want to support systems like Windows 98 ;o)

It's been a while...

...and I'm sorry. I intended to write at least once every week on this blog but it only lasted for about a month. I haven't exactly been out of work - we're in the middle of giving our house from the mid-1930 an extensive overhaul and I have currently had a two days vacation which I spent helping a plumber installing radiators in our house. I can truly feel how the lack of physical work in my day-to-day life has had a tremendous influence on my well-being today - I am simply flat out of energy and feel like I need a couple of days off... I haven't had the courage to ask for two days off yet because I'm quite sure I will get a counter-question similar to "You? Two days? You just had two days off!"... ;o)

Anyway - I have an article I want to share with you. One from the guru of OO (and a lot of other things) himself, Martin Fowler:


http://martinfowler.com/bliki/PreferDesignSkills.html


The article is about his personal view on which knowledge is the most important to you as a project manager - people who know design very well or people who has excellent specific knowlegde on areas which the project domain will be in touch with.

Off for now - have a load of work to complete before the weekend. If we're in any luck I get the chance to actually deploy something to production next week (first time for more than half a year - and I'm assigned to an Agile development team...).

...and a happy New Year to you too :o)

I got back to work today and was told to stay put until further notice because the team decided yesterday to upgrade to VS2008 - thus making our Buildserver unavailable and all our solutions needs to be updated with new solutionsfiles etc. What to do, what to do... I started off by reading the massive load of blog entries gathered for about a week or so and found this one which equals a getting-started tutorial to NHibernate. We use NHibernate on my current project but I have never had the chance to do more than just scratching the surface of this great product. The article is part of a series of articles called The Foundations Of Programming by Karl Seguin which touches areas as Test Driven Development, DDD, Unittesting etc. and are all worth reading.

I think this article is extremely useful to anyone who wants to get to know more (I won't say Advanced Basics because it is such a misplaced term) without digging deep into detailed issues. You can find the article here: Foundations of Programming part 6