For those long time IBMrs out there.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
THIS PAGE HAS BEEN INTENTIONALLY LEFT BLANK
.
.
.
.
.
.
.
.
.
.
.
.
.

D.I.Y and Project Management fusion

Whilst most people I know are off on holidays this weekend (Easter), I have the unenviable pleasure of decorating my house. Like most people I have been doing this for what appears like eternity. I wouldn't say I am a DIY addict, but I have completed my fair share of decorating rooms over the years.

So this weekend over the 4 days I have to decorate our hall, landing and stairs covering the ceiling, walls, woodwork and doors. Fit new door handles, hang pictures then prepare a bedroom and decorate ready for the new carpet that is being laid on Friday week.

Now, I actually quite enjoy decorating and once this sprint is complete I would have conquered the majority of the house. The people before us clearly never bothered with general house maintenance and as such we have had a few issues but I am pleased to say that it will soon look stunning and be a joy to live in.

The reason for the rush is that we have guests coming from overseas. I say overseas, I should say our homeland. We emigrated a few years ago and are lucky enough to have regular visitors from home. The only real trouble is that due to the regularity of visits people don’t notice progress. Especially those unpainted walls or the lack of carpet in such and so area etc.

I call it progress as I know the amount of effort that is required to make a room look great. I could have easily over painted the old walls and had a reasonable finish. But, I am an IT guy and I notice these holes in the walls, the creases in the wall paper above the door and window corners. I notice the way the light reflects shadows if the plastering is uneven and a light is on in the other room. I notice those blemishes on the wall that will be covered by a picture. Even though these blemishes are covered I know that underneath that they are still going to be there.

Perhaps, just a little, I am too much of a perfectionist when it comes to decorating, but I justify that due to my software development background. I can't craft code or applications with a bad user interface. Sometimes, I need to get under the covers of the code and reorganise and repair previous faults and issues. I wish that the previous owners of the house had invested a little time in their maintenance strategy!!!!!.

As I find myself re-engineering virtually every aspect of every room I can't help but wonder why those lazy sods did nothing.

Money could have been a factor, as could apathy, but just like with computer systems, a little bit of routine maintenance is much better than a re-architecting or re-building project.

Of the houses I have owned and renovated over the years two have stood out as being maintenance nightmares. After analysing the small amount of data I have available my only logical conclusion is to never buy a house from a couple whose surname starts with ‘T’.

The Tibbett’s and the Tankard’s. You know who you are!!!!!!!!!!!!!!!.

I have to plan to do some things in the most efficient order. I need to do detailed preparation for some areas and have to demonstrate my good time management skills, ensure key items are performed as per the critical path, and most importantly, I need to escalate any slippage in the project to the project manager ASAP. In this case my wifelet.

There is also the added pressure in that some of the tasks need to be performed out of standard business hours. This is to avoid kiddies fingers touching freshly painted surfaces and to minimise the odour of the paint fumes permeating throughout the house. So Saturday nights glossing will commence from 7pm until the small hours. If it is anything like before (another house) then I will see daylight before I see the bottom of the paint can.

Actually that reminds me. I do need to remember to check the paint levels, application tools (Brushes), removal and cleaning tools (Sandpaper and Turpentine) before I start.

This is a pre-commencement artefacts scan. Nothing worse than getting dressed up (old clothes) ready for the painting effort, only to realise that there is a fraction of the paint required to do the job. Then you have the decision to make. Do I drive to the DIY store wearing these old paint ridden clothes?, or do I change to something more practical for the purposes?

I should be OK with resources, i.e. me. Anyhow, adding additional resources to a project at this late stage tends to make it late anyhow. And with the dependencies for some of the tasks, adding additional resources now won’t help. Some things just need to be done in a linear fashion.

I remember an ex colleague of mine from years gone by called Yuriy. He was a wonderfully intelligent software technician, he had his quirks and an abundance of quality phrases. One that stood out in particular was “Lee, it takes nine months to make a baby, you cannot add nine women to the project to get it done in a month”.

Now Yuriy is quite right with this statement, although I guess if you do add nine women to the project then you have a higher probability of creating that baby and much more fun during the project initiation phase.

So touch wood, I should be ok this weekend. The resultant smile from the wifelet, the sense of personal satisfaction and the thought of those visitors saying. “Wow!, well done Lee, this looks nice………” should make it all worth while.

This most certainly seems like project management to me and apart from the deliverables (decorating) and a lack of written ‘signed off’ requirements ("Just get it painted"). This could be one of a hundered projects I have completed over the years.

So, always plan your projects, do your analysis and seek approval before you commence. My background in software development and management should come in handy even if it does feel like a busman’s holiday.

Happy Easter.

Thanks for reading.
Lee.

The new millenium Bug?

There are only 17576 combinations that can be considered when allocating a TLA (Three Letter Acronym) for airport codes. Part of the challenge is that the code should also be meaningful and identifiable, for instance, everyone knows that London Heathrow is LHR and that Berlin in Germany is BER.

If you don't believe me take a look at this site http://www.world-airport-codes.com/.

After a while some of the codes appear confusing. Hwanga in Zimbabwe has the seemingly obvious code of WKI. I assume this is pronounced Wiki.

This may be of interest to some of the IT geeks reading this, assuming of course that the introduction of Google’s Knol has/will obliterated the Wiki concept. I can never work out why open source stuff like this "Wiki" is so damn difficult to maintain. I guarantee that Google or Microsoft will make this easy for Joe Bloggs general public to use. I can personally hear the death knell for Wiki already, largely IMHO its own fault for keeping it geeky and for the myriad of different syntax styles that are available.

Anyhow, back to airports. With over 9000 airports registered in the database to-date and our insatiable appetite to travel around the world, it is likely that more and more airports are going to be built, each requiring yet another unique meaningful code.

Presently, these codes do not include numeric characters so the basic math tells me that there are 26x26x26=17576 combinations available. This is stated with the assumption that unlike car license plates, we do use every letter available in the alphabet.

So what is going to happen come the day when we have used up all these codes. We could begin to use numeric characters, however, the numbers 0,1,2,3,5 and 7 are unavailable due to their similarities with the O, I ,Z,M (sideways), S and L. Also, unless we have taken a big step into the future, a code like KN9 really sounds like a it should remain in a novel by Arthur C Clarke rather than a domestic airport in deepest Taiwan.

That said, there is more than one way to skin this cat.

We could be tempted to extend the size of the code from say 3 characters to 4, or perhaps more. However, this will require a huge amount of effort to synchronise all the airline ticketing systems around the world, not to mention:-

• Online and published guides.
• Signage (i.e. Welcome to LAX).
• All those travel agents whom for years had remembered these codes.
• All those flight anoraks who have travelled to every airport known to humankind.
• The humble fan website and all those pub quiz questions that have been written and are now negated.

All this hassel because someone decided to save a byte or two when naming the airports in order to save, at the time, valuable disk space. The irony being that this is the same disk space that the likes of Google and Yahoo are giving you gigabytes of just to sign up for an online email account.

It doesn't stop there though, what about the issued tickets that are already in the public domain. The transition period for change over would be huge (up to a year). So now we have to include all those check-in staff and the baggage handlers who now have to remember two codes for every airport into the debate.

I would suggest that the majority of those 9,000 airports have been created in the last 50 years. I find it quite daunting that we might experience the aviation equivalent of the millennium bug. This may not be that far off and once the developing nations reach full steam ahead with their expontential economic growth, you may well find yourself employed in the future to sort out the code written by those legacy developers.

Those same developers who didn't have the foresight to cater for tomorrow’s usage.

When we think about it, this has happened before. It was 20 years or so ago when it was concluded that 640kb of RAM was more than enough for any computing requirements in the home PC.

And those guys from the 70's that designed these airline systems have a lot to answer for. Not only did they earn good money back then with job security (outsourcing wasn't invented or trendy then). They now get rewarded for coming back in and fixing up their issues many years later.

So get travelling now. There might be some downtime in this industry and remember, someone has to pay for all this development. I pray to god (actually I don't as I am athiest) that you are using a 4GL like 2e or Plex to maintain this code. If you are using a 3GL you might have quite a lot of impact analysis to perform first.

Remember, you need to be extra cautious with your design and field domain management and regardless of what people tell you they want, look into the future and get it right first time.

Watch this space. You heard it here first.

Thanks for reading.
Lee.

What do you do for a living?

This has to be one of the most common questions asked of anyone in life. Apart from, How are you?, Can I buy you a drink? or cringingly, Do you come here often?. Well, this isn't an article about chat up lines or dating gotchas. I am long past all of that.

However, many people can simply reply “I am a plumber” or “Nah, I’m a sparky geezer!” (Electrician), or perhaps they might say "I have my own business selling cars" or "I work for a bank doing banking stuff". The point here is that no matter what they do, their audience will immediately be able to understand what they do and if they need their help or services, they can simply ask.

For the average IT geek, this is always a tricky and preferably avoidable question. We tend to shy away from disclosing our job because we are concerned about the impact of this little snippet of knowledge in the heads of a non IT savvy person.

There is a common phrase in IT that goes something like, 'A little bit of knowledge is a dangerous thing'. Actually, I guess this is true, in general. DIY being a good example.

As IT professionals we tend to try and answer this question ambiguously.

Mainly because we think that what we do is so very specialist and complicated, we also make allowances for the questioner as we believe that they will switch off. We have a primeval fear that we will not be able to complete communicating the fluffy, pinky greeny codey stuff, about why we love our job.

On this note, I do appreciate that in all professions there are general conversations and then there are the technical jargon and insider acronym riddled low level conversations.

As IT professionals we have invented more TLA's (Three Letter Acronyms) than any other profession, possibly with the exception of airport abbreviation naming committees.

Anyhow, a typical answer would be “Urrrrm, Computers”.

“Arghh, Right!!!” comes the reply, quickly followed by “Can you take a look at my computer?”.

And this is it, the single biggest fear of an IT professional. Your job might be that of a patterns and framework designer for J2EE or you may be a Mainframe performance specialist, but rest assured the simple mention that you work with “Computers” means that you are now their personal technical support helpdesk, for life........

Now, by contrast, our plumber and electrician are both in the home building or renovation trades, but, you never hear me asking them if they can do some plasterboard stopping, tile my roof or fit double glazing.

I guess that over time the general levels of understanding of the different roles within IT will improve. However, until this day has arrived I have learnt the hard way to always reply in a precise and exact manner.

"I specialise in software application modernisation, building and shaping high productivity development teams to meet the demands of developing enterprise business applications. I also provide bespoke consulting and training services and expertise in utilising multi-platform 4GL code generation tools.”

Now, for all but the most technical people out there, I tend to get that ‘lights out’ glare about halfway through that sentence, but, on the plus side, I also no longer get those requests for on the spot computer repairs.

Thanks for reading.
Lee.

Software Development Standards

Development Standards are an important aspect of software development. Whether you are a one man band developing a small product for sale over the internet or part of a multi-national multi-disciplined software development team, getting them right for your environment has a significant impact on your ability to grow and maintain your application.

Development Standards are all about best practices. This can be anything from a consistent screen design and menu layout right through to creating performance tuned code. Of course, in between there is a whole plethora of other important areas like architecture, naming conventions for your objects (tables, fields, programs etc), program layout, parameter interfaces, component selection and code comments to name a few.

A full list would be almost infinite and depends on the type of application, number of developers, platform, language choice etc as to what and how you implement a standards strategy. However, not having a development standards strategy is guaranteed ‘Developer Armageddon’ some time down the line.

Put simply, 90% of a software applications life is spent in maintenance mode. Not very nice but this is a simple truth of application development. Given this statement, it still amuses me that many software developers naively ignore development standards and certainly the importance of them during initial design and coding stages of a products evolution. I guess coding standards at that ‘Green Field’ stage of a project are not sexy, yet, this is probably the time when you have your best chance to positively affect the longevity of your creation.

I have witnessed development teams rush merrily down a rewrite in the newer technology/language/platform, only to rewrite the framework a release or two later.

This happens for two reasons, commercial pressures and time to market, but mainly through developer’s misguided curiosity and priorities. The developer is so eager to please their boss and desperate to use the new technology they naturally enter the feature race. A feature race is when a developer spends more time creating widgets and impact items for your application rather than design a sound framework.

Of all projects that I have worked on, the most successful are those that have been carefully thought out. A framework had been chosen/written, design patterns devised and standards implemented before the first line of production code had even been written.

Production code is quite an important term in this whole discussion. Too many shops go from prototype to production by renaming the application. People should be aware that the reason why car manufacturers make a prototype car out of clay is to ensure that it will look good and get early feedback. You don’t see Ford then add a couple of wheels and drive it away. Yet, time after time after time, this is how software projects start.

These are the projects that will hit framework 3.0, rewrite 2.3 and expiry 4.5.

So what are standards?

Effectively they are a collection of common points. They describe a common language, common style, common platform and environment techniques, common application attributes. Once everybody is doing their development in a consistent manner you have unlocked the door to a productive development environment, and that makes common sense.

So why do we need standards?

Most applications start off simple but over the years they invariably get more sophisticated and therefore difficult to maintain and grow. When you are dealing with thousands of programs and millions of lines of code it is quite obvious that having carefully applied standards would be more beneficial for software maintenance. Also that tight small development team that started the application development way back when is unlikely to still be the team developing/maintaining the application many years later. Therefore, these standards will serve the test of time and allow your application and organisation to change as these things do.

However, putting a standards strategy in place is one thing. As much as change is guaranteed your standards also have to evolve. Many are key development principles which apply to any situation and every developer, others need to be tweaked as things change whether that is new technology e.g. XML or identifying a better leaner way to perform an old standard. Be prepared to review your standards periodically and work extra hard to ensure that they are being implemented.

Ultimately the key issue about standards is the ‘buy in’.

It is absolutely pointless in agreeing a standard and then ignoring them. The best way to get developer ‘buy in’ is to involve your developers in the process. Ownership of standards is easy, they are owned by all interested stakeholders. This is from the Managing Director down.

So the standards are ‘ours’, the companies, they are a collection of guidelines to assist us in creating our application.

Strong standards and consistent implementation of the standards will improve our product, our productivity and our individual technical ability.

Thanks for reading.

Lee.