A roundup of Altio 2007

Wow, what a year 2007 was. It's been a hard year trying to achieve major things, and 2008 has been busy hence late delivery of this message.


I've been in charge of a lot of projects this year including

• deliverying a Graph tool and associated application for displaying relationships in data. The application is used by Compliance officers in big banks to assist in tracking suspicious transactions and relationships.
  


• the next version of Altio using Java Swing for the main infrastructure. Altio as a product has been around for a while and we are now re-positioning ourselves to challange Adobe Flex as a tool for creating rich web applications.
  

As well as the projects I've been in charge of the profesional services including recruitment and working with partners to design new system architecture (SOA etc) as well as talks about Altio. I'm really looking forward to 2008 when Altio 5.2 is released which will have the new designer and new controls, plus a simpler way of adding your own Java controls.

Testing - Tool testing vs Application testing

Over the past few weeks I've been in the situation where software testing has become a top issue. This is primariliy around the area of testing a Application vs Tools.




When testing an Application there are normally business users with defined scope of what they want to achieve. This means the scope of testing can be reasonably well defined and the testing applied in a structured manner.



Developing tools to be used as a development tool itself poses another issue, when is a bug truly a bug? To explain further you develop a tool which generates an application for you, and you go a step further and allow users to use a scripting language in the tool. The problem occurs when users find novel, and un-documented ways of using the tool which makes their own applications go wrong. Is it a bug? If you never told users they could do something that way, it's not documented anywhere is it a bug? Some people say yes - the reasoning is that if you don't prevent someone doing it a certain way then it should work. Others will say no - if users want to make use of undocumented features then they do so at their own risk.



I'm not sure there is an easy answer - I would like to think a development tool can be designed to bullet proof and not allow user to do things that will cause them tremendous amounts of grief. The problem is that in doing this you can be very restrictive and lose flexibility in the tool.

Cyprus Sunset - a week away from work

Cyprus Sunset, originally uploaded by garyt70.

Chill out week in Cyprus, kids loved it and I actually relaxed... well a few stressful minutes (kids don't allow complete relaxation).

We booked the villa through Holiday Rentals, the location was superb, easy walking distance of a quiet but pebbly beach or alternatively go to Coral Bay about 10-15mins walk. Coral Bay beach is ideal for young kids as well as teenagers.

Anyway I completely chilled out didn't check e-mails or mobile phone calls. Lots of fine food sitting in the sun and playing with the kids, weather was lovely.

Paphos water park was a big hit with the kids, although the scary part of adults is that you pay on the way out! You buy drinks and food using a wristband - everyone gets one. So if you're not careful the cost can soon add up when the little sprogs realise they can get ice cream on demand.

Had to do a few tourist things so went to Kato Paphos to see the ruins of the old town. The kids really enjoyed the Tomb of the Kings, you basically walked through all of the ruins, not barriers preventing them climbing into tombs.
Personally I'm not sure this could go on much longer otherwise things will soon get crumbled into dust

The only down side was coming home Paphos airport was a complete nightmare - 3 hours of queues.

Some photos can be found at Cyprus 2007

The importance of estimation!

An article on the importance of lines of code caught my eye the other day (Why is it useful to count the number of Lines Of Code (LOC) ?). I personally feel that the use of lines of code for estimation has several issues.

• Complex loops in code vs form code, it is possible to have a few complex lines of code in a loop and lots of code for generating a form. Verifying and fixing a bug in the loop may take a long time, while a fix in form code may take very little time


• What do you do about auto generated code produced by wizards? I would like to think that the code will always work so do you need to include this in the calculation. But, will generated code always work in the context of the surrounding hand crafted code


• What about abstracted definitions. For example in Altio much of the logic and screen definition is implemented as XML definitions and executed by the internal engine. The same is true for Adobe Flex and many other RIA development tools.
  

My preference, and idealistic, approach is to use a combination of several estimation techniques. Use Function Point Analysis (FPA) to determine the high level estimate (this works well for abstracted definitions). The FPA can then be used to generate an equivelant Lines of Code (LOC) estimation, this would be determined by relating the abstract definition to the equivalent Java code or C++ code (or any other language, users choice). Finally the LOC can be used in a structured estimation platform such as COCOMO which allows you to define the complexity of the system to produce and estimated cost and duration, finally confirm this all using Triangulation Estimation. I never seem to have time to do all of this and so feel the approach is best kept for large projects, or ones where you don't want a lot of explaining to do at the end of the project when it's late.

In my experience the Agile technique of using expert judgement and Triangulation Estimation will work OK. Well let's face it you get a pretty good 99% accuracy for the number of days effort to deliver.

In my opinion, however you perform estimation is a matter of choice, the important thing is to record the results learn from them and apply past experience to new estimates. Unless you purchase the software off the shelf or use past code and modules you will always be in new and uncharted territory, so how can you accurately estimate the distance you have to go to get where you want to be. Plus, users will always move the goal post making the original estimate nonsense!


Books by Steve McConnell
I've never read the book Software Estimation: Demystifying the Black Art but I have read Steve McConnell's other books Radpid Development and Code Complete both excellent books, and so assume Software Estimation will be equally as good.

Starting out

OK I've been thinking about starting a blog for a while. But wasn't sure I had anything I really wanted to focus upon. So I thought I'd focus on a blog about lots of things, or nothing at all. So there will either be lots of posts or nothing.

The thing that triggered blogging was doing something new and finding I had a little time to do it. Last Friday I left work a little early (well I'd worked over 45 hours that week, so one hour early is hardly a crime) and decided to go take some photos along the Thames in London. Heres a few shots on Flickr
http://www.flickr.com/photos/11326296@N07/1491933288/
http://www.flickr.com/photos/11326296@N07/1491922742/

So seeing as that was something new and I found I actually relaxed, for people that know me they're probably thinking "That's a first!". So another first is this blog.

So what do I plan to do in the way of blogs;
Software Engineering - thoughts on different technlogies, design methods, refering to other interesting blog sites I've been reading for a while e.g.
Joel on Software
Adam Bosworth

Just about anything else I find interesting and feel like recording for all to read. It really just all depends if I have the time, and think it's worth writing about for future reference.