Version 1.0

I thought that today I would blog a little about the concept of version 1.0.

There is a saying in IT that you never buy version 1.0 of a product. Obviously this can't be true as no new products would sell or make market penetration. Also, there must be those out there who enjoy the concept of working with an early version of a new tool or perhaps even a alpha or beta.

I guess these people can be summarised as conservative at one end of the scale or riding on the crest of a technology wave (rogue developer?, entrepreneur?) and the opposite end. They are clearly hoping to find the next super skill or application that they can become expert in, become recognised as an early adopter and advocate of the technology. Along with the kudos and recognition also comes the higher rates available.......Money, Money, Money..... "Its a rich man's world......". Guess who saw Mamma Mia the movie recently.

It was brought to my attention recently that an editor for a new game called spore is available on the Internet. The editor allows you the player to create your game characters.

Nothing too special at this stage I hear you say.

You are quite right but considering that the actual game is not currently available. At the time of writing it is 'gold' which means it is nearing release. I understand that millions of characters have now been created which is a pretty realistic barometer of the potential success of the game when it is finally released.

It is this model of releasing something early and benchmarking the idea that has probably allowed the developers to consider adding budget as required. How many people spend years building a product or website for that matter and then struggle to get sales or number of breakeven users to make the project viable.

Have we just witnessed version 0.0 as the new baseline and also a shift in mindset to a internet full of early adopters. Has the balance changed?

I will certainly think differently about the version 1.0 debates in future. After all, how do you get the balance between enough information to generate interest in your product or service but not too much so as to give away your plans and secrets to your competitors.

I will watch this unfold with a great deal of personal interest as I begin to build my online businesses and portals that I have been promising the world for so long.

Thanks for reading.
Lee.

The context of programming

Recent events in my place of work have lead me to ponder the concept of programming context once again. I suspect it is a pervasive concept as I seem to come across it on a regular basis in quite different circumstances. Let me explain.

If I am asked to write a program that accepts two numbers and returns a third number, being the product of the two, then there is not a lot more I need to know. Perhaps knowing the possible range of input numbers would be useful, but really this is a pure mathematical problem and has no context.

If I am asked to write a program that accepts two numbers and returns a third number - the number of residential addresses in a database that fall between those two numbers - then there is quite a bit more I need to know. I need to know whether just street numbers alone should be checked, or whether street names should be included (5th Avenue, for example). Even within street numbers alone, what about flat numbers? It's a bit more complex than the first example as there is a context. I.e. what are we actually trying to achieve here?

Now in a third example, I am asked to write a program that accepts two numbers (x and y) and returns a third number which is the number of active users who have been logged in between x hours and y hours. Again, now the context is complex. How do I define a "logged in user"? Do I define one interactive session as one user, or do I need to reduce this to unique users because some may be logged in more than once. What about "special" users such as system supplied IDs? Should they all be counted, none, or only some?

But the third example is even more complex than I have shown so far. Consider that this function needs to work in a function test environment, in an integrated test environment, and in production. There are some processes that occur only in production, some only in test and some on both. Will this affect the outcome? Is testing on the test system going to be good enough to know it works in production?

Hang on a minute - aren't we talking about system programming? Well, maybe yes and maybe no. If this program is needed to manage software licensing, then it's a system program. But, if it is needed to manage the number of customer service representatives assigned to different parts of the call centre, then no it is not system programming. If it is being used to achieve load balancing for application service jobs then it could go one way or the other.

Now that was a somewhat contrived example, but it helps me to illustrate my point. In all three cases, take two numbers and return a third. The first example I would expect absolutely any programmer to be able to achieve. The second example I would expect any programmer to be able to achieve if complete requirements are provided. If the problem is only defined as I described, then you would need an analyst programmer. For the third example, who would you give the job to, generically speaking?

This is where I see a massive gap. I, myself, have been fortunate to have been involved in both application and systems programming fairly extensively and even if I say so myself I think I'm pretty good at covering off the sorts of issues described above. It also means I am frequently seeing other programmers who are failing to account for the "system" level factors.

In a specific recent case, a developer insisted that my team (who are a development & test support team) replace one version of a program with another so that it 'behaved like production'. That should have been the first red flag. (I was not involved at this stage so I don't know whether I would have caught this at the start.) Why was the test system behaving differently to production?

Well, the developer got his wish and proceeded to begin to make his related code work. Meanwhile, large numbers of other people were tripping over the problems introduced. After several days of analysing the problems we concluded we had to put things back the way they were. To quote Spock - "The needs of the many far outweigh the needs of the few." This programmer was looking in far too narrow a context in defining what needed to be done. He had no concept of the roles this particular program was playing, nor the large number of dependencies it had. For instance, an automated regression testing suite completely failed because of the change.

But perhaps the most spectacular case of lack of context that I have ever encountered was in a previous role.

The product in question was enterprise software being used all around the world and it was incredibly complex. Customers had requested the ability to use off-the-shelf reporting tools (such as Crystal Reports) to create their own reports. The development organisation realised this meant less work on such things for us and considered this was a good idea - but dangerous. Great they can write their own reports, but how to let them into a massive, complex database without (a) massive confusion and (b) the opportunity to corrupt it.

So a plan was hatched to deliver a new library (for self containment) of logical files (views) which would collate the data into meaningful constructs and, importantly, be read-only. My team (again in development & test support) figured out how to deal with this new library for the purposes of the testing done on it. For the most part we just manually created and destroyed these libraries as required and used some of our own toolset which, importantly, is not delivered to customers.

At some point I got to thinking...How are we going to deliver this? The initial response I got from the designer was "on a tape/CD with the rest of it." To cut a long story short, I soon proved that it is impossible to ship a library full of logical files. Period. Can't be done. I took this information back to the designer, along with a rough sketch design of a simple tool which could alleviate the problem, and also be useful within the development shop.

The response? "We didn't budget for that." * Sigh *.

In the end, I wrote a quick (hack) version of that tool on the day we packaged the software. Some months later someone contacted me saying that there was a bug in my code. I sent them to the designer to have it sorted out.

Thanks for reading.
Allister.

2E - Development Standards (Defensive Programming)

Part two in the series and takes a look at defensive programming techniques and how these help you to create reliable programs.

The following a guidelines for creating robust code.

Always check for a divide by zero (runtime) error by checking the divisor field for zero value prior to performing the *DIV operation.

Never move numeric fields into a field with a smaller domain. With RPG this can cause truncation of the value and with RPG ILE Pre 8.0 will cause an RPG ILE runtime error.

Ensure that your iteration values and counters are large enough to cater for your anticipated maximum.

Ensure that your field sizes for database attributes are sized sufficiently to cater for the number of records anticipated.

Ensure that your arrays are sized to cater for the maximum number of array records anticipated. Thus avoiding array index out of bounds issues. Remember to balance this with not overly sizing the array and thus causing a performance degragetion.

Always ensure that any substring operations utilising position and length parameters are within the range of the target field. Thus avoiding substring out of bounds.

Remember to check the function options for your function to ensure appropriate behaviour, especially close down program and reclaim resources.

Never use the WRK context in new programs. Use LCL and HLL. If you choose to fix up old WRK fields, remember to check all other internals within your object and ensure that fields aren't used. This used to be used a trick in the old days to bypass the paramters passing limits. This was pre-arrays and when structure files where a pain.

Avoid HLL User Source and Programs. If you do write user source for RPG first convert program to RPG ILE and write one user source. The sign of a well managed and maintained 2E model is the percentage of HLL code versus generated code. If your models are more than 5% HLL then you have issues and a history of developers who have misunderstood the purpose and philosphies of model based development. IMHO.

Always pass parameters to user source. Do not rely on the generated field names.

Avoid use of CON context as these values are not available for impact analysis and localisation.

Avoid manual source modification. Use a program and the pre-processor directives to amend code automatically.

Source Modification – Special Notes.

Manual source modification must be avoided at all costs. If source is required to be overridden then a source modifying program should be written to automatically perform this function after generation and before compilation using the pre-processor.

In Summary:-

- Do NOT consider source modification unless absolutely necessary.

- Avoid the use of fields that use incremental counters for naming i.e. LCL Context YLnnnn.

- Avoid adding parameters above a field declared as a modified field. Therefore, always try to ensure that your fields that are parameters that are modified are at the top of the parameter declaration list.

- Try to avoid usage of fields higher than 32k. If 64k is required considered looping in 32k blocks as the 64k limit would one day be exceeded.

- Consider a naming standard to help you to easily identify a modified program and its modifying program.

- Consider centralised methods to ensure source modification programs have been successful rather then depend on a developer having to manually check the modified source.

Thanks for reading.
Lee.

2E - Development Standards (Performance)

This is the first part in a complete series of articles I intend to post regarding development best practices and standards for the CA 2e (Synon) development tool. The aim of publishing the guides is to educate, collaborate and enhance the standards by receiving community feedback. After all, no one person can know everything but the wider community can contribute.

Many of these tips I have learnt over the years and quite a lot have been sent to me by interested parties around the world. A big thank you to you all.

I will publish the complete documents on the 2E wiki (soon) with full acknowledgements. (See my links section below).

In the meantime I will publish some selected extracts on this blog just to get your thought processes flowing.

Performance

There are many considerations when programming for performance in CA 2e. A few are highlighted here. This is by no means an exhaustive list. My next technical post will relate to Defensive Programming techniques......

I'd be interested to hear of others from the community in general and would be happy to include them on this blog and the final wiki document.

Drop unused relations where possible and set others to appropriate level. i.e. OPTIONAL or USER etc. This cuts down unneccessary code and processing as well as making your action diagrams more easily navigable.

Avoid FLD for passing parameters for non command line type programs. Will use less PAGs.

Tactically use *QUIT to reduce I/O. Especially when programs have lots of nested validation logic. Very useful when validating. Use the *QUIT inside subroutines to halt further processing. Provides cleaner message feedback to end user and reduces response times.

Avoid Dynamic Selection Access Paths.

Avoid Virtuals, especially Virtuals with relations to files with Virtuals. Virtuals have their place. Query access paths or in scenarios where they are always used. Best practice in this area is to avoid virtuals and to get data as appropriate.

Ensure programs do not close down if called iteratively.e.g. in a loop or inside USER: Process Record etc for a RTVOBJ or PRTFIL etc. Typically used for externalised RTVOBJs.

Consider sharing ODPs.(Open Data Paths)

Consider usage of shared subroutines. Minimise the amount of code and reduces object size and makes debugging easier.

Consider usage of Null Update Suppression within your CHGOBJs. Very useful for batch programs.

Avoid unnecessary selector/position fields on subfile selectors.

Avoid contains (CT) selection on control panels

Ensure arrays are appropriately sized. Too large they will consume more memory.

Reduce file I/O by loading small reference files that are regularly read into arrays upon opening the program. Good examples here wsould be files like TRANSACTION TYPE or XYZ RULES.

Reduce I/O by only getting reference data only on key change. This will depend on the chosen access path of course.

When writing to an IFS write fewer larger chunks of data rather than multiple small chunks. Overhead is opening, positioning and closing the IFS file.

Pass reference data down through call stack rather than re-retrieve in the lower level function.

Consider physical file access paths for fix programs (version 7.0+) or write SQL to perform the basic updates.

Use OS/400 default values to initialise fields on a database file rather than write a program.

CHG/CRT v CRT/CHG. Use the appropriate one depending on likelihood of the records existence.

Avoid *CONCAT and *SUBSTRING native in 2e for long string manipulation. If concatenating for long strings it is possible to keep a counter of where you are to save the concatenation operation time to identify the current position in the string.

Avoid RTV message to build strings with high usage.

Consider DSPFIL instead of DSPTRN, especially true if de-normalisation is designed in the database with any total duplicated into the header record.

Do not perform a *RTVCND for blanks. Check for blank first in the action diagram.

Consider a database file field for *RTVCND if approriate.

Be aware of the affect of a scan limit for strict selection criteria as the screen will not pause load processing until the subfile if full or EOF reached. Particularly for large files.

Consider the naming conventions of your access paths to ensure that underlying indexes can be shared when key subsets are apparent and ensure that are built and implemented in the correct order to reduce indexes.

Ensure access paths have correct maintenance option i.e. *IMMED, *DLY or *REBLD.

Thanks for reading.
Lee.

Knowledge capture & use in technical support communities - Part 1

This three-part article is adapted from one I wrote almost 5 years ago when much of what you will read about was fresh in my mind. This adaptation addresses only the passage of time and some points of style and meaning for a wide audience.

Whilst software development is the subject of this blog, let us not forget those who (typically in large organisations) support the developers and others.

The nature of technical support communities.

Technical communities come in many forms, be they design teams, development teams or support teams.

Whilst design and development teams are largely about the creation process, they still have many day-to-day activities which are defined and repeatable. Support teams, although fulfilling an entirely different role, often have to create on a very short-term basis. So it can be seen that the different types of teams have similar requirements.

However, the support team seems, most often, to be the one to get out of control. The difference is that the support team is always working on a short time frame. In addition, support teams often become involved in project work and this adds to the complexity of the day-to-day activities, as the time frames are shortened still more.

Most often, you will find that staff in a support team are very good at what they do - they have to be to survive. Unfortunately, the higher the skill of the staff, the more reliant you are on those staff to keep the systems running. It is a difficult and time-consuming option to bring 'green' members into the team.

How many support managers have not recognised that documentation is a key part to the support process? I would wager very few. Fewer still, I propose, have succeeded in completing the documentation requirements within their team and reaped the kinds of benefits they were expecting.

Documentation, to the 'tech', is a four-letter word. I, myself, recall asking the question "Do you want me to document it, or do it?" Simple economies prevent the techs from having enough time to complete the documentation task and many welcome this excuse not to do it.

Another trait of support teams is the experts. In virtually any support team, there will be experts in various disciplines. Most often, however, these experts are relied upon to provide most of the resource in fixing problems in their area of expertise when they should, in fact, be called upon to share their knowledge.

Shared knowledge is a powerful tool. Experts will always be needed when particularly difficult or unusual situations occur, but the team as a whole should be able to leverage the experience to improve task turnaround times through a more even spread of the load.

Knowledge transfer

It has been documented in studies that the best way to learn something is to have an expert stand over your shoulder while you go 'hands on'. The reality of the situation in front of the learner, coupled with specific and pertinent comments or instructions from the expert gives the learner an experience often indistinguishable from the real thing. The learner also has the opportunity to ask direct questions in the context of what they are doing. Book learning, on the other hand, can only go so far with static examples and predetermined situations.

Perhaps the most important aspect of 'over-the-shoulder' learning, however, is that the expert is unlikely to simply recite steps by rote. There will be an accompanying commentary and usually a significant amount of reasoning on why things are done that way. This is very important in equipping the learner for when things do not go to plan.

Learning the steps of a process by heart is well and good when the process works. Most often, however, processes do not cover all possibilities and the rote-learner of the steps is going to come unstuck when an unforeseen, or simply undocumented situation arises. Unless the learner understands why they are taking the steps and what they should be achieving, they are almost as much 'in the dark' as prior to learning the steps.

Having knowledge about the nature of the process and the goings on under the covers helps get through many small deviations from the norm and also helps in issue resolution, as the learner is able to return to the expert with an hypothesis, or at least having done some basic checks suggested by the nature of the operation.

The key issue with this type of knowledge transfer is that, in the majority of cases, the expert is already overworked and has no time to spend standing over shoulders.

A secondary issue is that the expert may have to impart their knowledge, over time, to a number of different people, and this is inefficient.

The 'Virtual Expert'

From what has been discussed so far, it is clear that expert knowledge is required, but that tying up the expert in this process is seen as unproductive in most situations. We cannot get away from requiring time from the expert, but we can minimise this time and capitilise on it by recording the knowledge in the right way.

In part 2 of this article I will go into methods for capturing this knowledge in the most effective way.

Thanks for reading.
Allister.

What makes a good software developer?

I have decided to move on from my current role after over four years working at my present company. My reasons are varied and plentiful but as always the lure of a fresh new challenge often commands the majority of my thoughts.

I have started once more on the interview merry go round, first with agents and then in the coming weeks with potential employers. This is an interesting time in my career and certainly a change I am looking forward to albeit a little nervously as I have only ever had three IT related job interviews in my life.

During my early stages of interview with one particular agent I was asked a really good open question. The question was “What makes a good software developer?”. I waited no more than 2 seconds before I began rattling off my opinion. Normally in these situations you take the time to consider what you want to say and then lead up to the answer.

This felt different.

I guess this is because although I have never answered this question before (personally or via my blog), I have hired enough developers and non-developers over the years to understand what I believe a good developer to be. After all, one of my own interview questions to potential new hires is “Why software development for a career?”

I ask this question as I want to know what motivated them to get into software development and what maintains that desire to be a software developer. At my last firm a new project manager joined and we got talking about stuff. You know, the technical stuff. It was quite obvious to me that this guy didn’t want to be a project manager and that he still harboured that technical development desire. I knew this because as a project manager he would say stuff like “Worst case I can write that program.” or “Couldn’t we do this in x language or y language.” It was pretty obvious to me that this guy couldn’t let go, and this is what I look for.

For me the number one thing is the passion. I want to see this in the eyes of the candidate as they express to me their achievements and technical prowess. I look for the body language that backs up these passionate views.

I have been part of and built software development teams. I have written in other posts that you do need a mixture of people at varying stages in their careers with a good balance of personal motivating factors. Passion is certainly the one I look for when I am considering the lead roles within a team. The reason being that I believe as a lead developer you must bring others on by example.

Other factors to look for, especially for a permanent employee are:-

* Longevity in the industry and loyalty to an employer or two.
* Proof of learning multiple languages and having the desire to adapt to development trends.
* Good understanding of general development concepts and practices.

These are pretty generic but with passion, loyalty, desire, adaptability and a good all round understanding of development I believe I can teach any developer the technology of the month.

Without these attributes I guess you could be selling your business short. If I had to choose one then passion is the one I would go for.

If you see a developer struggling with some code all day but eventually they let out an enormous scream of relief as they finally solve their issue, jump up and then start punching the air in delight in the style of Rocky Balboa.

I’ll have that person in my team any day.

Thanks for reading.
Lee.

Where's the dishcloth?

Bugs!!!! Love them or loathe them, realistic developers understand that bugs are part of our everyday life. We have technical bugs, environment bugs, business logic bugs, integration bugs, somebody elses bugs and god forbid, stomach bugs.

Now apart from the stomach bugs. Who is responsible for clearing up this mess?

There are numerous approaches depending on the product(s) you have developed, your organisational structure and your focus on bugs in general. I prefer the ‘zero tolerance’ approach to bugs, however, others are quiet happy to have a level of bugs in their code and apply risk and cost ROI calcualtions to determine whether the bug is recitfied, and if so, when. I feel there is a whole post on that subject alone and I’ll save that for a slow news day.

Moving back to the tactics around who should be responsible for clearing up this shoddy code. If you work as part of a small team of developers or lone wolf it is likely you have little choice other than to get the developer who wrote the code to fix it up (look in the mirror). You are unlikely to have development support teams who act as dedicated bug fixers or access to a stream of developers on the graduate recruitment programme that fix up the bugs as part of their development induction process. The later two are certainly perfectly valid approaches although a little old fashioned in my view, after all, who trains up new recruits in the process of only showing you how not to write good code.

Personally, I believe that the developer who created the code should be the developer who fixes the bug. Obviously this won’t happen if they have left or are away on annual leave or a significant amount of time has passed, but in general it would be good practice to follow this process through. There are many fine reasons for either approach and no doubt I will conclude with some views around this a wee bit later.

For now, I prefer to use the anology of those everlasting worksurface ‘tea rings’ when referring to bug clearing methodologies.

“Tea Rings!!!”.

Yes you heard me correctly. Consider the communial kitchen in your office. You probably visit this vicinity between 4 and 10 times per day to make that cup of espresso stimulus or the relaxing afternoon chai tea.

The process is quite simple. You will carefully choose the serving vessel and may even warm it through first. You will likely compliment your brew with milk or cream and sweeten to taste, unless of course you actually listen to the advice of your dental hygienist and drink water only. Whilst queueing patiently for the kettle to boil like the quintessential englishman you will definitely have pondered your preferred order for mixing these ingredients. Water or milk first probably being the most important choice and certainly the one that has polarised the tea drinking world for generations.

More often than not this process is repeated throughout the day and with the exception of having to raid the dishwasher for a preloved teaspoon it generally goes without a hitch time after time after time. Software development generally pans out this way too. Once a developer becomes productive and uses your best practices they will be able to make a good brew (code) with no mishaps (bugs).

After all the effort analysing, prototyping, designing, creating and ensuring adherrence to your quality control processes you are finally ready to move your code (brew) to production or systems testing. From time to time though there is that unsightly spilage around the base of the cup as you pick it up. These are those tea rings that are etched on every spare post-it note pad on your desk or the coat the surface of that old CDR you are using as your cup coaster, the same coaster that once contained the backups of your companies servers.

So who is the best person to clear up this mess. As the creator it should be a small matter of picking up the nearest dishcloth and wiping the worksurface clean. But wait. When you look at the mess you notice that there are other tea rings there, some sugar mounds and a spattering of breadcrumbs from that cheese toasty you could smell from the other side of the office earlier. At this stage do you clean this lot up as well.

You may elect to wipe clean your own mess only, expell a little more elbow grease and time and clean all of it or choose to ignore the tea ring as in the whole scheme of things, it is hardly noticable in amongst the remainder of the mess. For me there is only one satisfactory approach and that is to deal with the issue as soon as it arrives.

It only takes seconds to analyse the problem and take effective corrective action. If you choose to mop up all the mess then you must be aware of the dependencies of fixing up all the issues. What appears quite simple may take longer and if the mess is particularly ingrained you could actually damage the efforts of others.

Doing nothing though really isn’t an option either as this creates an environment that bugs are satisfactory. Housekeeping is just as important in the office kitchen as it is with keeping your code and products bug free. If you do favour seperate teams or graduate programmes for doing the teams dirty work, imagine for one moment how they feel knowing that they are merely cleaning up other peoples mess.

Lastly, how are your developers ever going to get better and improve your product if there are no consequences for producing shoddy code in the first instance.

Thanks for reading.
Lee.

"It's a funny old game."

This is a phrase that was immortalised many years ago into the educated soccer commentators punditry. To this day it is associated with the footballing legend Jimmy Greaves. He however denies that he has ever muttered these hallowed words, but I clearly recollect him talking to Ian St John on the Saint and Greavsie Show on numerous occasions. But if the man himself denies it then I guess I must be mistaken.

The ‘Saint and Greavsie show’ was a Saturday morning football preview show with a combination of the video highlights from the previous weeks games, interviews, opinion and a review of the upcoming games on the Saturday. With the advent of Sky and the commercialisation of the beautiful game, this show would now be a review of the upcoming games on the Saturday, Sunday and Monday.

I have been working in the software development business for far too long. My roles have ranged from day to day software developer, those with project and team management responsibilities to my current position of technology advocate for the CA 2E and CA Plex toolsets, specialising in enablement and best user practices in enterprise sized software development environments.

I often use analogies referring back to football to simplify describing issues or ideas to members of my teams, in fact, I find it rather amusing to compare football management to software development practices and the careful balancing act of creating high productivity software development teams.

My thoughts thus far are that the art of football management and that of software development team management have numerous parallels. I would historically refer to the construction industry or the car manufacturing industry to derive a comparison for the creation of the software product itself. But, when shaping your team it is quite clear that you require a myriad of skills, approaches, characters, opinions, ego’s, attitudes to name just a few of the attributes required to form a modern day software development team.

You will need to give careful consideration to your preferred team formation, management and coaching staff, youth development plans, team captaincy selection, picking the players for a particular project, substitutions, dealing with injuries to the squad, career mentoring as well as dabbling in the transfer market. The prospective number of parallels appears almost infinite.

So where do you possibly start?

I guess you have to look at yourself (The Manager) and decide on your style and approach. Are you going to be a hands on tree hugger or a hardnosed disciplinarian. i.e. A Steve McClaren or a Fabio Capello!

You then need to employ your trusted backroom staff (coaches and medical team). It is highly possible that as a manager you were also a former player and you probably still retain most of the skills required to perform many of the roles within your team, but be warned, if you do find yourself doing rather than managing then this is a sign that you have the incorrect balance in your team.

A manager that believes he can do every role within the team and often gets sucked into the detailed coding on the teams projects is guaranteed to be holding back the team come match day. He needs to empower his team with clear instructions and tactics in order to navigate the perils of developing quality software systems. His role should be to conduct the performance of the team from the broader viewpoint on the sidelines.

Your coaches are your technology evangelists. Their role is to ensure that the team fully understands industry best practices for your technology implementation and they are responsible for the day-to-day training and fitness of the players. These guys educate the players and control items like development standards and peer review processes. They play a pivotal role within the team to provide feedback about a player’s progress and readiness. The medical team are your DBA’s, they ensure that your players are in peak physical condition and provide ideas for improving performance and integrity of the team and products.

With the manager and backroom staff in situ along with the assumption that you have finalised team tactics and on field communication strategies, it is now time to concentrate on the squad.

The types of players that you have are critically important. It is imperative that the right mixture of roles and personalities are employed. It is no good having an entire squad made up of day coders or similarly overloading the human resources entirely out of super-coders and architecture astronauts. (Thanks Joel for that gem)

Great football teams have a mixture of leaders, defenders and all-rounders, as well as, specialist roles like striker or winger. These roles will have varying objectives and performance targets and are likely to be rewarded with differing pay levels. Generally, a striker will command a higher salary than a goalkeeper or a defender, they will also be motivated with bonuses linked to the number of goals that they score during a season.

Age is also important. Consider a team of 17 year old apprentices playing against a group of wiley old professionals with all the life experience caps that they have attained. Balance is a key element of this article and age along with the relevant fitness, naivety, passion, rawness and nerve is equally as important as any other attributes that make a strong team. Historically and with the only exception in soccer being the Busby Babes. Succesful sporting teams in general would have a mixture of ages.

All members of the team will have their objectives set at the start of the season and reiterated before each game. In fact the Post Implementation Review after the game will significantly affect the managers decision making for future games.

The yearly budget you have available will determine the number of star players that you can afford to employ. Just like when creating a fantasy football team online you will need to ensure that your team performs as a whole and doesn’t rely on a few heroes to score you those all important fantasy points. It is the same for a software development team. You can’t rely on a couple of heroes to do all the hard graft whilst the rest of the team sits back and watches. It is proven that heroes do not scale.

The type of project is also an important factor. The race for the league title could be considered a release of the software. Meticulous planning is paramount and this generally represents the highest team priority for the season. A cup competition could be described as PTF or service pack and generally has less lead time and the items of work are more random in scope and type. Emergency patches, I guess, would be extra time in a knockout match that has been tied after the first ninety minutes or the all important penalty shootout that the English always seem to lose.

Now that you have assembled your squad and understand the scope of your requirements you need to consider the team formation. Do you go for an attacking formation and line up for a project or a defensive approach? You can certainly draw from experience with similar projects and previous games against the same opposition. Do you go for an industry standard 4-4-2 formation or an attacking 4-3-3 with more focus of scoring goals with the risk that you may concede more.

So what roles do your players perform for your development team? Do you have a team of permanent players or do you have some on loan (contractors). You then have formation and player positional issues to consider.

Your goalkeeper is your gatekeeper. Their sole focus is to ensure that no errors make it into the production software. They perform the system regression testing.

Your defenders are your process converts and quality conscious developers, their stalwart approach ensures your projects have fewer bugs. These players traditionally lack flair and innovation and the technical ability to complete the highly intricate activities so should be avoided for high pressure or groundbreaking assignments. They are however, tenacious and determined and just as important to the overall performance of the team as any other team member. The defenders love solving configuration issues and enjoy debugging other developers code. They are advocates of unit testing processes and even talk to the testing team. There are of course exceptions to this sterotype, especailly in the modern game where the technical ability of players has been improved from the days of Chopper Harris.

Midfielders are much harder to quantify. They are generally the fitter members of your team and have the ability to perform many roles throughout the team. Some are specialist defensive minded players who protect the defenders with the extra level of security. They enjoy performing peer reviews.

Every team needs a playmaker. This is the person who enjoys having extra time on the ball and loves playing that killer pass to open up the projects defence. They are dead ball specialists and keen reference book readers.

Your wide players have speedy boots and code at a frenetic pace. They can sometimes trip up and get caught out of position but the times when they do get beyond the defence to create opportunities for the strikers can be crucial for a project that is running behind schedule. The amount of running they do during a project often ensures that they need to be substituted during a game.

The striker’s job is to produce the goals. They like to code all the sexy aspects of the deliverable. They tend to prefer GUI development to batch processing and they definitely pay lip service to the art of unit testing. They are generally calmer under pressure and have sublime belief in their own abilities which can lead to a sense of laziness as they tackle most projects with aplomb.

You also need to consider the preferred kicking foot or development skill. There are positions like wing back or winger where delivery is paramount. Having a rightfooter playing on the left or a leftfooter on the right has both good and not so good options. Again, with the modern game this is being phased out by two-footed players who have been nurtured since birth. But if you do have a one trick pony in your team then you need to consider their involvement carefully.

Getting the balance of your team right is important. Too many strikers and you will fail with every project as no-one wants to do the grunt work. Too many defenders and your project timelines will consistently slip. Every team needs to be carefully balanced, coached and briefed on the preferred ways of working.

It is a shame that so many managers just don’t understand the dynamics of a highly productive software development team. Perhaps we need to ensure that software development managers obtain their coaching badges and have performed at a professional level before progressing into the management arena, after all........

It’s a funny old game".

Thanks for reading.
Lee.

For those long time IBMrs out there.

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

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.