Eurotunnel...

The hiatus is over; in death is renewal and the realisation that we are indeed mortal.
One
Anyway back to the subject of this blog, software.

At present we face a number of software engineering challenges amongst these is the centralisation of field application logs(FAL). SaaS appears to be a natural solution to this problem. The service interface would ideally accept a log message and persist this for later consumption by development and support staff.

Stuck in traffic

device drop

Some thoughts on home grown code gen

The context: I have some xml that needs to be converted to C# class files. The xml is attribute-centric.
Possible implementation: transform using xslt, tokenize xml and use tokens to populate template; use Codedom ap; use code gen tool
Preferred option: CodeDom/Tokenization strategy

Applying Scrum in a non-software development context

My experience of agile project management is confined to the field of software development, but as luck would have it, I have an opportunity to apply agile in an industry sector where brawn comes before brains. Well that's not entirely correct, but I guess this domain thrives on a command control type structure. I will definitely need to adapt the methodology to take into account the cultural differences afterall we are dealing with complex adaptive systems...ahem

Oh so this is SAP

Recently started working with SAP as a data model for our .NET UI. All very exciting at the moment. Objects are modelled using a tool and each instance of an object is stored in a construct called a table. Associations and aggregations are aslo modelled using the tool. As someone once said "it's dejavu all over again". Based on these observations, I posit that SAP development exemplifies DDD. The ubiquitous language is developed as the model is formulated, dependencies amongst objects are also modelled accordingly. What I am yet to encounter is the notion of value objects. Entities are an intrinsic part of object definition.  Blogged from me Android...

That's your spec sir...my first foray into the world of haptics

What we have here is a meal planner structure which can be digitised and form a module in our Home Information Management System(HIMS). In this era of the Smart Meter and the Media Center, there is definitely a place for HIMS.

220 Downloads later…

A while ago I put together a little library that determines internal rate of return for a series of cash flows. This is a problem in the accounting domain and was prompted by the inadequacy of the features in excel. I did not want to haul the whole of excel into the application I was building. I tend to stay clear of Interop if I can help it.

Well the short of it is that the lib averages 1.5 downloads per day. Not much for 15 mins work, but this has led me into thinking that perhaps there is a larger market for reusable math/scientific libraries. How about a DNA sequencing lib?

Now clean it up…

In our attempt to clean up software engineering and make it a more rigorous profession, I assert that testing is one tool that will ensure that the discipline produces consistent results and repeatable quality. Testing should be at the forefront of a developers’ mind, but in most cases it is an after thought. I suppose this is a reflection on the human condition. We are forever optimists hoping that our artefacts will stand the test of time.

Well I don’t live on hope and for me life is a set of precise constructs. Gravity always wins and code breaks. So lets get test-infected.

Writing a good tests assumes:

• A knowledge of the domain or access to a subject matter expert – can be the product owner
• An adequate tests framework
• A testable architecture

As someone once said, “any one can write a programme, it takes a disciplined developer to write code with tests”.

Balancing the risks of tool switching – a heuristic

When/why should a team adopt/change its toolset?

• If the current toolset is inadequate and results in a loss of productivity
• If the new toolset is a ground-breaking innovation and not merely a derivation and solves the business problem better than the incumbent
• If there are compliance/regulatory constraints that mandate the change – for example Sarbannes-Oxley.
• If the new tools will give you significant competitive advantage in the market place, otherwise the costs of learning/deploying the tools will erode marginal benefits

When should a team not adopt/change its toolset

• Because it will look good or make the developers appear smarter when included on their CVs – remember the customer has to deal with mess once you have left the site

The day we overloaded the scrum with issues that were not part of the “triumvirate”

The context: A distributed team with very minimal inter-personal contact. Most conversations are by electronic means.

The scrum started out with each engineer being asked the usual trio of questions. The expected responses were given and then a tangential conversation about the best approach to take for a new project took root. Big mistake! Before long we had a virtual bun-fight that risked creating permanent schism within the team.

The lesson to learn from this saga is that face-to-face sessions are best when discussing issues bordering on religion. Once a jihad has taken root within the team then delivery of quality software will be impossible because the team is working against itself.  As a facilitator it is tempting to give additional bandwidth to groaners and the loudest shouters, but this has to be weighed against the greater needs of the team to work as a cohesive unit.

We have survived the death march…what’s next

After the intense and somewhat heroic efforts by the team, a retrospective is definitely apropos. The key lessons learnt are:

1. Scrum definitely works when used in a chaordic context. What might appear as the ritualized trio of questions, what did you do yesterday, what do you plan to do today, what are the impediments to progress, focuses the development team on what needs to get done.
2. Working software is the ultimate measure of progress on any software project. If it’s buggy you will have trouble gaining the trust and required acceptance and signoff.
3. Short feedback loops via daily stakeholder meetings help focus the development team on what needs to get done
4. Having a developer who also happens to be a subject matter expert will propel the team further.
5. Don’t change the domain model if it’s not broken. A distinction has to be made between purely technical changes and changing the semantics of the model.
6. Regression issues will undermine the team and erode user confidence
7. Make your tech choices before hand and adhere to them
8. Beware of feature envy - http://c2.com/cgi/wiki/Wiki?FeatureEnvy
9. Keep the testers close and the customers closer
10. Retrospective testing of code is much harder than TDD.