Performance and expectations

Although this post is rather short, I do write it.

At this very moment I'm waiting for a file-copy. I have an image of a virtual machine on an external USB drive (WB Passport Elite 250 GB, good drive!) and want to copy it to my fixed harddisk on my slow laptop (why are these things so slow within a year?). While waiting for it I'm able to write this. The expected time to finish was 16 minutes. So that is the time my laptop takes for copying a 16.081.982 kilobyte (about 15.4 GB?) file from an external disk to my internal laptop disk. Amazingly slow... it is about 1 GB/min = 16.5 MB/sec.

In the meantime it finished and it took 19 minutes and 12 seconds! Wow, that's a lot of time copying bits (so rougly 13.8 MB/sec. that's SSSSLLLOOOOWWW). And this is nearly an optimal situation because the file is one huge file. If it were a few thousand files it would probably have taken a something like 2 hours.

Why I started writing this? We all expect more than we easily get from technology. The new waves of technology are highly appreciated all the time until it has become a few months old or a commodity. But replacing things all the time can't be afforded by anyone, so we have to extend the use and lifetimes and make sure the investments are returned in the ratio we like it.

The link with what I do for a living is here! I want to start a few blogs related to projects, performance and expectations. I'm currently actively building up a "project offer" which helps in delivering projects very fast (max few months), providing good performance (in terms of speed of development and availability but also ROI) and fulfill and manage the too much underestimated expectations.

Later!

<

The Principle of ‘Results Beat All’

"The top strategy is ‘getting the stakeholder results’. Meeting requirements is more fundamental than any other process or principle."

The above text and principle comes from the writing of Tom Gilb. From his Competitive Engineering (CE) book. I'm kind of a fan of Tom Gilb. Since I got into touch with EVO, a "methodology" which could be seen as an early Agile approach of software engineering.

I just read the text because a tweet of him brought me to 100 CE principles, which are very valuable to "us". It triggered me because last week I had a tough dicussion with some people about the current status of a project.

In that discussion I was searching for the reasons of why the project still wasn't finished. The roughly expected date of delivery was about 3 months ago, but the end of the project is very hard to see and predict. I understand all excuses and reasons for not delivering yet but really can't understand that there is almost no understanding about having a HUGE problem.

I explained the team that we are not able to see any results now and that we expected to really SEE progress every sprint. The reaction was that a lot of progress has been made and that there is a lot of software that is of high quality, very flexible, future proof and now only the front-end has to be finished. And if I had taken the effort to look at the code and other non-functional artifacts, I could have SEEN progress (so it was "my own fault that I didn't see progress", WT*???). And of course, the expected date to deliver the system was unknown. No wonder we still have projects that never end or are way too late/expensive.

How can we become happy and build up trust if we don't meet the requirements? (the requested ones, with real value!). Having top-notch software without having delivered any requirements is worth nothing and therefor not really valued by the stakeholders. The top-notch quality software is normally implicitly expected.
The answers is of course to deliver the requested results by meeting the requirements. It is very simple but still not easy to get it done. And besides that, the progress transparency is adding trust. Show the progress made, the efforts it took and how long is still needed for delivering the remaining requirements agreed upon. Estimating may be hard initially, but try and improve...

The summary of this is that it's very wise to follow the basic rules and principles of proven approaches. I apply Scrum and will improve+adapt it where needed. But the basic goal doesn't change, deliver results ASAP!
The top strategy is ‘getting the stakeholder results’. Meeting requirements is more fundamental than any other process or principle.

Currently I'm working on a project approach to show and emphasize the focus on results. We expect to help customers with some short term need in one month!
When we start a project we need the global requirements and the required result. Together we create the product backlog and focus on the stories that make a system valuable and usable after ONE month! Of course not every project is completely done after one month but we are fully focussed on getting the stakeholder results available ASAP. Finishing, beautifying, fully integrating and extending the system afterwards is perfect common sense. But the value and results are there and our customer starts gaining from the added business value NEXT* month!


* if we are able to start NOW, we deliver NEXT month.

<

Microsoft Tag, that's what it is.

In my previous post I posted an image. That image is a tag. Tags are used worldwide for tagging, identifying and pricing articles and products. Now Microsoft created a new web oriented tag which in my opinion may become a huge success.

Read about it on the site of MS: http://www.microsoft.com/tag/

<

Find out what this is...

This picture can be machine read (even a mobile phone). But what is it?

About IT and business value

The crisis is a pain. In our business of IT-expertise consultancy weird things happen... The hourly rates are very much under pressure in a lot of cases. Even below cost price is seen...!? Is that because the business value of IT solutions is dropping (and the returns are lower than expected) or is it purely the crisis circumstance that costs are cut.

Both are probably true. But how would we solve that?

(We or) I focus on real business value delivered as soon as possible. Not waiting until the full solution is done, tested and approved. No, what can be delivered and result in actual business value, that must be delivered and used for business ASAP. And then we proceed with adding functionality that will even add more business value. And so on, until the added value will become lower than the costs. This mechanism gives ROI from an early moment and brings business and IT closer together. Narrowing or closing that gap between business and IT

Should IT be seen as costs? In a lot of organisations, IT is one of the bigger elements of the "general costs". But is that smart? In many situations IT is a requirements for the business and even the enabler or even the reason of competitive advantage. Is something that important a "cost"? Is it wise to cut that kind of costs?

Is IT not a main ingredient of normal modern business? Is it wise to increase that ingredient OR to lower it. I'm not talking about the costs but about the power of IT. IT can be applied very effective if you want, then it enables your business instead of being a high cost.

It's a matter of vision and the way we organize our business and it's value.

Become lean and agile and focus on value!

<

Getting to use GIT?

Git is a relative new player on the version control playground. A few years ago Git saw the light and was brought by one of the smart guys on this globe. Linus Torvalds; he needed a distributed version control tool to maintain the Linux kernel and seemed not to be too happy with the tool they used before Git. The exact story can be found somewhere else... (some links here)

I didn't use ALL of the possible version control systems but I guess I've seen about 6 or 7 different systems and all of them had pro's and cons, and from free+working to very expensive+not working. The latest I used was SVN and I thought it was OK. But now we start more to use some Ruby/Rails related tools and as a side-effect Git came by. The CI tool Integrity is the one we want to use and it seems to support Git out of the box but not SVN... Now what's wise to do?

I had a quick and global look at Git and created some repositories on Github and have to say it's easy to use... Of course things may change when I start to use the more advanced features but the basic use seems to be OK. So I'm able to make the step to Git!

And.. before I forget...
If you have some SVN repository and would like to try Git with your own stuff, Github provides a way to import your SVN repository. I also tried that and was glad to try some things out with some code I already knew...

BTW: a nice starter may be: http://www.pragprog.com/screencasts/v-scgithub/insider-guide-to-github

SOA and complexity

SOA was the next generation of the modern solutions in IT, right? Yes it is, but why?

SOA is a rather vague architecture of how to create an very manageable, flexible infrastructure for all your current and future applications. But what's the SOA best practice. Ask the big SOA-package providers and they all offer a kind of similar story. It's always easy, connecting applications can be done in a snap and BPM and BAM will make life easier. If you create and follow the right plan and have a clear vision of the measurable goals, then you could get there. I really don't want to sound cynical, but bigger IT systems are complex [period]. And a SOA infrastructure may not pay off for the smaller IT systems. So SOA means complexity!

Complexity is not the same as "impossibly". Manageable complexity is what it's about. Enough cases do exist where the complexity may not be simplified. That's too bad, but make sure it's manageable! Unmanageable complexity results in unexpected problems, misuse and higher costs and may even create business risks.

Lowering the complexity starts with the awareness that SOA is a way to optimize your organization and therefore your business. SOA probably will not pay off if the business won't benefit from it.
(Of course enough people will try to use SOA as a technology replacer, but then the replacement will lower costs and provide new/extra features. I think that the business case will not benefit the business but may lower costs (especially when mutli-vendor middleware is being replaced). This happens of course, but that's not what my current blog story is about!)

So my advise... SOA is not a bad idea but is also not very new. The SOA term, terminology and current open standards provide never seen before integration possibilities (you remember CORBA?).
So.. At least think about the needs, the complexity, the manageability and make sure it's going to deliver value (preferably to the business).