This blog contains articles related to the practicalities around
application software development.
In this blog, I'll offer opinions and advice on the following topics:
- multi-platform application development
- skills required for future commercial programmers
- definition of "commercial software development"
- why versioning is important
- supporting migration, coexistence, fall-back
- what to think about when writing commercial software
I'll hope to answer some of these types of questions:
- How should source code control be
- When should secure engineering be employed?
- How can teams
maintain software for their sucessors to own?
I hope you find this information useful for your career and the software development that you are responsible for.
I see that I had high hopes of becoming a consistent, but not prolific blogger back in November 2010 when I started this blog.
And since then I've not updated it at all - as they say - life interfered.
So, as I begin the new year, I am re-doubling my efforts to be much more diligent in adding information to this blog.
This first entry for the year will only contain a couple of topic ideas for future blog entries. Here are some things I've been thinking about as trends for Application Modernization and Commercial Software Development:
- Application Modernization is not a single pass process. It is a process of continual renewal (much like the maintenance one does on a house or other asset).
- The biggest issue/impediment with programming and for programmers is to "get started".
- The second biggest issue/impediment for programmers is to "stay engaged and on task"
- Multi-platform applications and application development is the future - and the future is now.
- There are aspects of writing software that apply to all practitioners ... and yet very little of these skills is taught through formal education:
- coding for the next person to read and update your code
- design and coding for migration, coexistence, and fall-back scenarios
- design and coding for forward and backward compatibility
- design and coding for multiple active versions deployed into production
- design, coding, and testing with security characteristics in mind
- Enterprise Architecture, Application Portfolio Management, and Enterprise Modernization are tightly related
I hope to spend time on each of the topics above in the coming weeks and months.
I have spent the day today educating myself on IBM's Service Oriented Model and Architecture (SOMA) method. Why, you may ask. Well, as I look across the Rational product portfolio, we have a bevy of product offerings that are available for teams to use. These products are jam-packed with features and capabilities. So jam-packed, in fact, that the tools can be overwhelming at times.
One way to provide focus for architects, project managers, application developers, and test teams is to have them follow a well thought out process, using tools such as the Rational tools to support their work.
So, as part of my desire to help teams a) get started and b) stay engaged and on task, I find myself interested in how best to show the Rational tools being used at various stages of a application development process such as SOMA. Teams following a SOMA method will have clearly articulated tasks to accomplish, and my hope is to show the Rational tools (a combination of Rational Team Concert, Rational modeling tools, Rational requirements tools, Rational application development IDEs, and Rational Testing tools) being used in each of these tasks.
I have seen that alignment has been done in the past between SOMA and the Rational Unified Process (RUP). This was a good start and was appropriate at the time that the work was completed. However, times have changed and both development processes and product portfolios have evolved since that work was completed several years ago. It appears that it is time to re-assess SOMA and the Rational tool-suite to show how both complement and support one another.
I had the good fortune to speak with a colleague of mine yesterday on this topic.
He and I agree that these two areas - Application Portfolio Management (APM) and Application Modernization (sometimes referred to as Enterprise Modernization) - are very much related to one another.
Indeed, APM is a process by which teams relate their business goals and priorities to their information technology (IT) assets, deciding which assets to refresh, rewrite, rehost, retire, replace, or refactor. And as siuch, APM work spawns application modernization work!
But there is a feedback loop involved as well. Since smart teams make informed choices as to what path to take, the tools used and information gathered to perform application modernization is critical in making informed decisions about the organization's application portfolio. Thus, application modernization efforts feed information back into the APM process for the next spin through the analysis of the portfolio and determination of what direction to take the IT assets.
You can think of APM as a cyclical process which spawns application modernization projects. In turn, these application modernization projects are cyclical and feed information back into the APM process for the next cycle of portfolio analysis.
For those interested, the Rational products of interest for these areas of work are:
- Application Portfolio Management
- Application Modernization
These tools are complementary, with different team members making use of them at different stages of the APM and application modernization process steps.
I have recently started using the term "multi-platform application development" quite a bit. But what do I mean by this term?
From my perspective, as I look across a wide range of application development teams in many different industry sectors, what I see is a steep rise in the number of platforms, operating systems, and programming languages being used to provide complete solutions. Rather than the computer programming converging on a common application infrastructure or programming language, I see that the programming task is becoming more and diverse.
The industry has stated for years that one of the keys to extensibility is to have clearly defined interfaces and employ loose coupling to enable freedom of choice of platform, runtime environment and programming language. It appears that the industry has succeeded in this! That is the good news.
On the other hand, by having such freedom, applications tend to become combinations of multiple different elements or components, each running in their own environment, with their own constraints, capabilities, and limitations. Testing and debugging such applications starts to get much more complicated since the set of dependencies (on what must be up and running, or somehow scaffolded to appear to be available) rises with each loosely coupled element in the overall system. Furthermore, the team that provides one component may not always be available when there are questions related to that specific component.
Because of the rise in platforms, runtimes, and programming languages, coupled with the necessity of organizations to streamline their IT staffs, including programming staffs, as much as possible, there is now increased pressure on application development teams to be able to switch from platform to platform, from runtime to runtime, and from language to language with speed and laser-point accuracy. This is the essence of multi-platform development.
Just because an application is built of a loosely coupled set of components, each written in whatever language is most appropriate and running on the most appropriate system, doesn't mean that a programming staff only needs to worry about one small part of the solution. Application development teams are responsible for the entire solution and thus must be ready to take on the management, maintenance, and enhancement of the entire application, no matter what platform, runtime, or language the piece of the solution was created to run within.
In summary, multi-platform application development is the idea that application development teams will need to be increasingly platform-nimble and language-nimble in order to be the most productive and most valued assets to the development staff of their organization. The application programmer that can move freely between platforms, runtimes, and languages will be easiest to re-align to the ever-changing needs of the organization to meet its business goals. Application development teams should be thinking about how to be multi-platform savvy as they improve their programming skills.
In one of my previous blog updates I noted that the hardest thing to do when writing software is getting started. I figured I would explain myself a bit more in this post and give some links to some useful information for those who are possibly new to the Rational application development tools.
The task of writing software, either creating it from nothing or editing existing software to make changes and enhancements, is a task that requires focused attention and concentration. Anything that provides a distraction or pulls the person away from the specific task they need to accomplish simply gets in the way of the programmer. Because of this need to concentrate on the task of programming, it is very difficult to "get into the zone". And once a programmer is in that zone, the last thing you want to do is pull them out. For doing so will just require them to spend the extra effort and time to re-engage and catch up to where they had left off when they were interrupted.
The day-to-day tasks of the application programmer require similar tasks to be performed over and over. These include accessing source code, finding a particular location in the source code that needs attention, making those changes, building a test driver, and testing the changes to the application that the programmer made. These steps are performed countless times by programmers, no matter what language, runtime environment, or platform they are working on.
The Rational Developer tools (for System z, zEnterprise, and Power Systems) are well-suited to streamline the tasks noted above. As such, after they have been set up appropriately, these capabilities help the programmer make an easier task of getting started on making changes (i.e. it's easier to "get in the zone"). And once the programmer is in that zone, the integrated development environment (IDE) helps to keep them engaged on completing that task.
The following links contain videos which show off some very basic examples of using the IDEs to do these common application programming tasks. I hope you enjoy them:
There are many more instructional videos on using the Rational tools located at the IBM Education Assistant website. I hope you find these useful for getting your team started and keeping them on task!
This posting is a bit off-topic from Application Modernization. However, it is related, since everybody has a need to use what are known as "office productivity" tools.
I have been a long-time Linux workstation user. I have enjoyed using the open source operating system and have found it to be, in general, the best environment to suit my needs as a developer at heart. When I was in college I used mostly SunOS and Unix-style environments and thus I always had a soft spot for a good command shell. But I digress.
As a Linux user, my options for "office productivity" tools were somewhat limited. After looking around, I became a Open Office user and have found Open Office to be quite good at documents, presentations, and spreadsheets - the three main elements of an office productivity tool-suite that I use most often. There was nothing I could not accomplish in Open Office that would necessitate my using MSOffice. Interoperability with my colleagues who were using MSOffice file formats (.ppt, .pptx, .doc, .docx, .xls, .xlsx) worked reasonably well, with only minor re-formatting required for most files.
But I was always on the look-out for other tools that could be used. In looking around, I decided a couple of days ago to give Symphony 3 a try. I tried Symphony 1.x in the past and was not impressed with its capabilities. I have to say, though, with Symphony 3, the user interface is much improved, to the point that I think it is more polished than Open Office. Having worked with it for a week or so now, I am thinking that I will switch to using Symphony 3 for the forseeable future. The interface is a bit nicer than Open Office and it's screen rendering seems just as good.
I suggest you give Symphony 3 a try. It's available for Mac, Linux, and Windows and ready for you to try it out.
One more note - I recently had an article published in IBM System Magazine - Mainframe EXTRA edition - see here. The article discusses multi-platform application development and the rising need for application programmers to be multi-platform and multi-language savvy. Enjoy.
I have stated before that the hardest part about application development is getting started. What I mean by this is that it takes great effort to get one-self into the mind-set and position of actually designing a piece of software or writing a software program or routine or building that source code into a program or testing that program to see if it runs and so on. Performing this task takes a strong will and focused concentration on the specific task at hand. In many cases, other distractions such as e-mail, instant messages, facebook status, SMS text alerts, and even the phone need to be turned off or ignored just so you can get into the necessary level of concentration to perform the task at hand.
There are times, though, especially when first learning how to use some of the application development tools that are available, that being able to ask questions, get answers, and interact with others who are working through similar situations is an incredibly productive way to understand how to perform a task or learn a feature about the tools that you were not familiar with before. Reading through product documentation can be boring and difficult, especially with most documentation only available in electronic format. On the one hand, electronic format is easily searched based on keywords. On the other hand, everyone has, at one time or another, found what they were looking for more quickly by fanning through the pages of a book until something catches their eye, either in a figure, a section title, or a code snippet that they saw as the pages flew by. This latter method is not well covered by electronic book formats.
To address the needs of application developers of all skill levels learn how to make better use of the tools at their disposal, there are several discussion lists available free of charge and backed by the developers of the tools themselves. We call these discussion areas "cafes" to give them the feel of places where people can come together, talk about issues or successes that they have had, and generally find out how to make use of the wide array of features in the Rational application development and application modernization tools. If you're an application developer and you haven't looked at the Rational cafes, I encourage you to do so at your first opportunity (there are links at the end of this post). You can just watch and read or contribute your successes and questions to the cafe discussion, it's your choice.
These cafes help application developers get started. They ease the learning curve for using the tools, and serve as effective "how-to" documentation to fill the gap between product manuals and personal experience. Use them!
The top level link for much of this information is:
I keep hearing that COBOL skills are in decline. But for some reason, I just don't believe that this is something for organizations to worry that much about.
Here's my reasoning.
Stepping back from all of this, what strikes me as most interesting is that the number of computer languages that people are becoming at least conversant in is rising, not falling. And on top of this, if a computer programmer is good at anything by the time they have obtained their degree, it should be the ability to pick up, read, learn, and create new programs in languages that they, at first, are not familiar with. This is just the way the software industry is headed. Softwarwe engineers will need, as a prerequisite of getting a job, the ability to learn and use languages that are "new to them".
And so, that being the case, the world is full of potential COBOL programmers! There's not a shortage of them any more than there is a shortage of C/C++ programmers.
Now, what is difficult is learning new run-time environments and new application development environments. Figuring out all the details of how to access source code, how to edit it, how to compile, debug, and test it - those are tough things to pick up. We get used to using the tools we're familiar with, and our muscle memory takes over and helps us be even more productive in the environments where we're used to working. This is where having development tools that ease the access to and usage of unfamiliar environments come to the rescue. And that is where Rational Integrated Development Environments (IDEs) such as Rational Developer for Power Systems and Rational Developer for zEnterprise come in.
So the next time someone laments to you the lack of COBOL skills, think again. I think there are millions of them available ... they just don't know it yet.
As I read over my posting from late last week and thought about this situation a bit more, I kept coming back to the term I used in the title of this posting - skills portability. I believe that application development teams will be challenged increasingly to be able to move, quickly, from project to project and from application source code base to source code base with ease, precision, and speed. In such an environment, teams and individuals will need to be multi-lingual (programming languages), multi-platform, and multi-environment savvy. These teams will have to switch from environment to environment to perform their designated tasks. In this way, these teams will have to be able to adapt their skills to different environments, thus requiring portable skills or the virtue of skills portability.
How is this possible? Does the current computer engineering or computer science curriculum emphasize such skills development? Is there a set of educational materials or exercises that will hone such skills? I think that the answers to these questions lie not in the specific courses that students take, but in the ways in which the courses are taught, the tools and environments used for projects and homework during the classes, and the emphasis on tool usage that is made both during education and on-the-job training that takes place during internships and in a permanent position.
There seems to be something of a quantum gap between "heavy tool users" (those that rely heavily on the capabilities of an integrated development environment (IDE), build automation tools, and emulation/test environments) and "command-line users" (those that are masters of arcane commands such as 'ls', 'mv', 'find', 'grep', 'make', and so on). For a person to move from one of those environments to the other is quite an effort. Everything is different. Seemingly simple tasks turn into hours of drudgery or Internet searching to find the answer. Even moving between different command-line environments can be a challenge. Commands are different, options are different, and editor styles and features vary widely.
Moving between different platforms, languages, and environments when using an IDE, however, seems to be quite a bit easier - even if the IDE is different from one the user has used in the past. A user of and IDE is already familiar with the need to "hunt around" through the menu bar or context menus to find an appropriate task. Users expect fly-over help and visual cues to guide them in "doing the right thing". In this way, I have found that users of IDEs wind up being able to transfer their skills between multiple languages, platforms, and runtime environments much more quickly and effectively than those who are experts in the particular command-line tools of the particular platforms that they are used to using.
In summary, for skills portability, I encourage teams and individuals to take that quantum leap into learning and using an integrated development environment (IDE). It will be painfully slow for the first several uses. But you will make back that investment in time saved, precision, and the ability to apply your skills to a wider platform and runtime environment set that otherwise possible.