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.
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
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
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...
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.
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?
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:
As someone once said, “any one can write a programme, it takes a disciplined developer to write code with tests”.
When/why should a team adopt/change its toolset?
When should a team not adopt/change its toolset
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.
After the intense and somewhat heroic efforts by the team, a retrospective is definitely apropos. The key lessons learnt are:
With an impossible deadline on my back and a tangle of excel spreadsheets as my spec, I punch the keyboard, but the juice fails to flow in the IDE. The first test says nothing about the problem I am solving. The coffee is insipid; the Ipod sounds like a broken digital record…perhaps the copy and paste coders are on to something…but I let that thought pass. Why bother with reuse if they refuse to use my API. Do I detect NIH?
Refactoring is now a common term in the developer’s vocabulary. However what most developers call refactoring is really hacking. Making a change to the code in the hope that it will work is somewhat analogous to smoking a cigarette whilst filling up your petrol tank. Both will inevitably end in tears. And this is where the dogma kicks in; it is not really refactoring unless you have a safety net of automated tests to verify that the state of the universe has not changed since you last updated that pesky connection string. A bad test is better than no test at all. I guess that leads on to my next topic…false positives and false negatives. But for now get testing and buy a diesel.
