Experiences from my first application
I recently completed my first "proper" application, which is a program for assisting our sales and aftersales teams towards better data capture at point of sale.
I work in the Motor Trade as a marketing manager. The company I work for has a large database that is badly in need of some organising and some serious management. The lack of management is not down to a lack of will, but down to a mixture of very poor tools and a lack of accountability at the operator end.
The problem is probably best illustrated by describing the data error report that is currently in use.
The report was written several years ago, and examines each customer record on the following criteria:
For string fields: Is it populated?
For date fields: Is it populated? Is it in the future?
For eMail addresses: Does it have an @ in it?
The output is a bar-chart split by department and dealership giving the percentage of records which comply with the above criteria.
As you may have guessed, the report is very simplistic. However, this is not in itself the source of the procrastination. The real source of the procrastination lies in the report's applicability as a management tool. The thing is, although the Senior Management can identify which department, and therefore manager, needs attention, that manager cannot identify which of his team is not collecting the data they need. In departments which see thousands of people in a month it is difficult to identify who is not putting the data in correctly, and to actually put the errant operator on the spot or give praise to those who make the effort requires a lot of effort and a skillset they don't generally need.
So, the solution was to write a program which scored each customer record, and allowed the user to drill right down to the individual operators, and what they had actually put into the database. It would also takes a much harder look at the data and asks questions like: Does this customer have a well-formed eMail address? Does this customer have a UK mobile phone number? And also quite importantly (particularly from the perspective of this narration) whether or not the record referred to a human or to a company, or to a human working for a company.
So that's what I did. And it works! I'm particularly pleased with the way that the staff who have been testing it for me have responded - they have taken it seriously and been motivated by the scoring system and the way that it gives them detailed feedback on how they can improve their score. Not to mention the opportunity to compete with the other dealerships.
Anyway, whilst that's all very exciting there have been some interesting lessons learned about good program design and the real challenges of developing software in the real world.
I'm going to go into each of these in detail in separate posts, but a short summary of each are as follows:
Understanding the problem creates the solution: Basically, the better you understand the problem the more likely you are to design a good solution. I'm not referring to class design or programming design, I'm referring to linking the ouput back to the problem you really need to solve.
Work like hell on the design: Although this has not been an entirely straightforward experience, for any class or interface, the difficulty of writing the program was inversely proportional to the time I spent designing it.
Aim for modularity: Always try to keep classes and objects as dissociated from their peers as you can. One of the key mistakes I made in my original design was to rely on inheritance to create my data structures, rather than composition.
Look for existing solutions. One element of the program uses a chart package that I decided to write myself. The Java FX package is much better, free, and was written 6 months before I started mine. I could have saved myself several weeks of delay if I'd used it, and the program would look a lot better.
I'll go into more detail about these later, however one thing that does strike me when I read over what I have written is that I was well warned on all the above - anyone who reads about programming and software development will recognise these points and probably be able to tell their own similar stories.
I work in the Motor Trade as a marketing manager. The company I work for has a large database that is badly in need of some organising and some serious management. The lack of management is not down to a lack of will, but down to a mixture of very poor tools and a lack of accountability at the operator end.
The problem is probably best illustrated by describing the data error report that is currently in use.
The report was written several years ago, and examines each customer record on the following criteria:
For string fields: Is it populated?
For date fields: Is it populated? Is it in the future?
For eMail addresses: Does it have an @ in it?
The output is a bar-chart split by department and dealership giving the percentage of records which comply with the above criteria.
As you may have guessed, the report is very simplistic. However, this is not in itself the source of the procrastination. The real source of the procrastination lies in the report's applicability as a management tool. The thing is, although the Senior Management can identify which department, and therefore manager, needs attention, that manager cannot identify which of his team is not collecting the data they need. In departments which see thousands of people in a month it is difficult to identify who is not putting the data in correctly, and to actually put the errant operator on the spot or give praise to those who make the effort requires a lot of effort and a skillset they don't generally need.
So, the solution was to write a program which scored each customer record, and allowed the user to drill right down to the individual operators, and what they had actually put into the database. It would also takes a much harder look at the data and asks questions like: Does this customer have a well-formed eMail address? Does this customer have a UK mobile phone number? And also quite importantly (particularly from the perspective of this narration) whether or not the record referred to a human or to a company, or to a human working for a company.
So that's what I did. And it works! I'm particularly pleased with the way that the staff who have been testing it for me have responded - they have taken it seriously and been motivated by the scoring system and the way that it gives them detailed feedback on how they can improve their score. Not to mention the opportunity to compete with the other dealerships.
Anyway, whilst that's all very exciting there have been some interesting lessons learned about good program design and the real challenges of developing software in the real world.
I'm going to go into each of these in detail in separate posts, but a short summary of each are as follows:
Understanding the problem creates the solution: Basically, the better you understand the problem the more likely you are to design a good solution. I'm not referring to class design or programming design, I'm referring to linking the ouput back to the problem you really need to solve.
Work like hell on the design: Although this has not been an entirely straightforward experience, for any class or interface, the difficulty of writing the program was inversely proportional to the time I spent designing it.
Aim for modularity: Always try to keep classes and objects as dissociated from their peers as you can. One of the key mistakes I made in my original design was to rely on inheritance to create my data structures, rather than composition.
Look for existing solutions. One element of the program uses a chart package that I decided to write myself. The Java FX package is much better, free, and was written 6 months before I started mine. I could have saved myself several weeks of delay if I'd used it, and the program would look a lot better.
I'll go into more detail about these later, however one thing that does strike me when I read over what I have written is that I was well warned on all the above - anyone who reads about programming and software development will recognise these points and probably be able to tell their own similar stories.
Comments
Post a Comment