3.10.09

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.

19.8.09

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.

26.7.09

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”.

10.7.09

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