As we start seeing the light at the end of the RMR tunnel, we are on time, on budget! But is it purely down to my masterful planning and estimating skills? Or are other factors at work? Well the planning is in the right ball park, but as I started to ask myself if we could have finished any earlier, two things dawned on me. 1) Project Teams work to a given deadline and are unable to realign to an earlier one 2) Although Quality, Cost and Funtionality are all within the required boundaries, there are ways to cut corners without affecting them, when viewed from a high level (e.g. the project stakeholder) In terms of the former, I think it is well known that if you assign a task and allow a given time for it, it is very likely to take that long if the time allocated is realistic. It takes dedicated individuals with something to win by delivering early, in order to do that. The latter point relates to having loose requirements specifications from the customer, and moving requirements driven by the development team as we designed and engineered the solution. It is relatively easy to convince a customer how to change the system to make it easier to develop, when he cannot sit down and play with it to see if the proposed solution will work for him. It's like building a kitchen and negotiating using a different cupboard that is easier to install. If it…
Month: June 2007
Testing Migration Processes Early
When preparing the final stages of your project, you need to start thinking about delivering your system into production. Typically you need to pass from development environments through to testing, integration, user acceptance and finally production. In order to have a good plan that can be successful, here are some things that you need to consider: 1) Are the processes already in place to allow smooth transition? 2) Are there good guidelines and quality assurance procedures involved that will ensure repeatable deliveries? 3) Are all the technologies you are using already in production? 4) Is there experience of how long a typical migration through all environments might take? 5) What is the absolute fastest time that the migration cycle can be completed in? 6) What are the "no go" traps? What quality assurance points are in place that could stop your migrations? 7) Is your build process entirely automated and fully repeatable? 8a) How many people are involved in the migration process? 8b) How many of the people involved in the migration process do you know face to face? 8c) How many of the people involved in the migration process can you go and physically sit next to in the event of problems? 9) How many companies are involved in the migration process? All these points, and surely more, can have big impacts on the delivery process. I recommend doing a trial delivery very early on so that you can discover what the hurdles are. Of course, some quality control…
EJB Frustrations
This is by far not the first time I had worked on a project with EJBs (Enterprise Java Beans, see http://java.sun.com/javaee/), so why am I still amazed at the time wasted in the development of them, relating to configuration issues, compiling time (double compilation due to RMI requirements), slowing down of development environments due to the vast resource requirements of application servers, and obscure error messages? That last point deserves expansion - on Websphere, not only do you sometimes get strange CORBA related error messages on the client which have absolutely nothing to do with the problem, but you also get orb trace files secretly dumped with no warning! And similar on the server with the ffdc traces that get dumped, with a very simple warning message printed in the logs... I recently reviewed our current system to ensure that errors in logs were extremely concise and at the same time provide the exact details that second and third level support needs to resolve problems. Unique error codes, showing the customer the timestamp to report, User messages as well as technical messages in the logs for support staff, and so on. Shame application server vendors couldn't do a little more to make developing on their systems somewhat more efficient...
