Most of us find we are not keeping up with our job...
...there is not a moment to breathe, we work long hours, we are rarely finished on time, and the pipeline is endless. Whether it is maintenance, or new projects, we are overcommitted. And, unfortunately, this means that in general, I.T. has a reputation of rarely finishing anything on time. Ultimately, that responsibility is ours, yet we get caught up in the same cycle of development, and rarely step back to look at the bigger picture.
When I perform strategy sessions with I.T. and business, the usual result is an aha moment. In one case, we discovered a requirement of over 30,000 project hours required to finish the projects that had been promised in a single month. When I realized they only had 3,000 hours to apply to these tasks, I thought the customer would be upset. Yet, they were pleased that, for the first time, they had better visibility into their committed projects, and were able to do something about the over-commitment.
Not all of our companies will support the time, effort and cost of a strategic review of our I.T. organization, and we are left to deal with the same repetitive cycle of going nowhere. In my experience in the IBM i community, there are several ways to eke out some extra time in our day to allow us to become more productive in our efforts. Some of these are obvious, some not so, but they all need the occasional review, and today is your lucky day to read about a couple of them!
Applying simple time management to your daily activities can have a very positive impact on how you apply your skills to your job. For example, spending ten to fifteen minutes in a morning to review your planned tasks for a day can improve your productivity - sometimes by an hour or more. Time management is, of course, qualitative, difficult to quantify, and different for everybody. Finding the right time management discipline to suit your own work style, your teams work style, your departments work style and/or your companys work style requires some research. Ironically, it is going to take some time to invest in this research, so it is quite imperative that you start somewhere. For some people, starting their day ten minutes earlier than usual can be the first step in a major shift in their working paradigm, resulting in some serious productivity gains. Never underestimate time management as a productivity technique, however, unless you do it...
And it goes with saying, interruption management is a means to improve your productivity. Even though we are all geniuses at our job, we tend to underestimate the impact of an interruption. While we all ~know~ it only takes one hour to build a new query or report for a user, we forget the time spent on the initial requirements checking, and we forget the time spent reworking and tweaking the report until it is just right. A one hour estimate in our genius brain will more than often be a two to eight hour job. Sure, we are doing our job of supporting the users, but that two to eight hours has now been taken out of our existing assignments. We will then spend longer hours and weekends to make up the time for the projects with a deadline, and all because we did not manage an interruption for a single report. There is much more to interruption management than can be written in this blog entry, and, again, it is worth the research to improve your productivity.
Modern Development Tools
The majority of customers I work with are still using outdated green screen development tools. Outdated, because IBM have stopped adding features to the ADTS (Application Development ToolSet). ADTS is the collective name for the set of tools that include SEU, SDA, RLU and PDM. The modern replacement is an IDE named Rational Developer for Power - RDPower. You may also have heard it called RDP, since some green screen historians still cling to a plethora of TLAs - comfort abbreviations if you will.
RDPower is a complete tool set providing a work desk that can open multiple source files at the same time. Some of the espoused functionality is the ability to verify source - basically, a full compile on your PC without creating an IBM i object, instant links to invalid or out of syntax code, cross-reference visibility to database tables and columns (think files and fields) used in the program, offline source code editing, etc. - the list is very long. Simply put, the list of included functionality brings IBM i application development into the 21st century and beyond. Yet, many IBM i developers still use SEU as their primary development tool.
Other than being the right tool for the development job, RDPower will improve a developers productivity. Most of the industry experts teaching RDPower suggest one day a week improvement in productivity, even up to two days a week. In my experience, it is closer to the two days improvement in the medium term. The barrier for most IBM i developers is usually one of two things. Fear of change, or fear of change. Often, they are personally scared of learning a new tool, and reject change for what they believe is changes sake. However, would you invest two to three weeks of learning to gain at least one day a week in the long term? It is a simple equation, but ignored because it takes developers into a new world - one that is very different than PDM and SEU.
For the most part, the typical IBM i developer will find RD Power, and the Eclipse platform on which it is based, to be extremely foreign. It will require learning some new things, and for the first few days, you may feel rather stupid. If that puts you off, you will end up rejecting entreaties to modernize your developer skills, and stubbornly stick to what you know. The psychological phenomenon that is occurring is simply ignorance - lacking in knowledge, but feels much more like stupid. I encourage you to push through stupid, and persist. If you can survive the first week of learning, RD Power will become familiar and improve your productivity.
For me, the cool part is that Eclipse is an open source development tool, and you can find - both within and outside the IBM i community - a sizable list of plugins to help you improve your productivity even further. Given that 2008 was the stabilization of ADTS, new language features - such as Open Access for RPG - are only included in RD Power. If you wish to be a modern RPG programmer, using a feature rich language, the only way forward is RD Power. And, if you are already an RD Power user, tell someone else how much your productivity has improved - spread the word!
The second fear of change comes from business or management. There seems to be a major lack of understanding when it comes to (a) acquiring RD Power
(b) upgrading RD Power, and (c) paying for RD Power. Traditionally, ADTS cost money, but was wrapped up in the purchase of the server hardware, OS and software package. Today, your company may not have purchased RD Power, and now (all of a sudden, apparently), someone realizes there is a cost and management decides it is not worth the money.
Part of the issue is a comparison of a (perceived) free ADTS with a (perceived) expensive RD Power. Again, it is an issue of investment and return. The cost of RD Power is competitive per seat with most modern development toolsets, including Visual Studio, its main competitor. It is a relatively small investment when you consider the improvements in productivity gained by each developer. The difficult part is how to convince your company or I.T. management that this is a good investment. And that may be where your research skills once again kick in.
In this blog entry, I have covered two means of improving your productivity. The next will be covered in a future blog entry, and suggests IBM i developers should understand how to be more than just a Windows user. In all cases, this is your own career. It boils down to being your own responsibility to research the tools available to you. Without understanding your own future, you are doomed to code like you did in 1999, maintaining productivity levels of the past, and living in a cave. There is a light outside the cave, but you have to find the switch.