Design and Develop Large-Scale System Software
This is the sixth and final post in a series about things they never taught me in school. Over the years, I have taken many different computer classes in schools, through IT companies and by self-study, but nothing prepared me for the rigor of leading a team in the design and development of a large-scale system software product that was expected to be used by many hundreds of customers. Let me explain.
Planning and Design
Working with a commercial software product requires a comprehensive plan that covers all aspects of the development and delivery of the product. I was given a template to use that guided with basic planning mapping development line items to categories and tasks. It also included a set of milestones that involved getting approval from diverse stakeholders during each major step of the development process.
When a product has many dependencies within a company, steps are taken to keep all stakeholders informed, offering them the opportunity to change the schedule of the product or stop its forward movement altogether if they see problems that can’t be fixed to their satisfaction. As the project leader, I learned that keeping the project on schedule and managing communication and relationships with stakeholders is important and time consuming. Nothing I learned previously prepared me for this. In the planning stage, I also met with legal, marketing, contract and negotiation, and other teams that had work to do regarding this product before it went into the marketplace.
For this product, the design was focused on line items that were either new functionality requested by one or more customers and functionality that was needed to retain compatibility with the OS or key middleware like CICS and IMS. We were using a kind of waterfall method so the design was created in a document that was agreed to by the developers and shared with the stakeholders. A template was supplied for this work product and, since the product was to be used internationally, there were elements of the design that were new to me as this was my first international product. I learned that simple things like building the product outputs was challenging, as they needed to be translated to other languages. This was an example of one of the new things we had to consider. Nothing I learned previously prepared me to fully understand what it meant to develop a program that had to comply with internationalization guidelines.
Development and Testing
Three small teams carried out the development efforts and a series of systems were required for each team including development, systems test and support. These many systems ran in OS instances running under VM. Coding was done in CMS and since Rexx was the main programming language used, code changes could be tested vary rapidly as we were using a language that was interpreted in real-time and compiled at a later time. Needless to say, there’s a lot to keep track of when there are many different instances of the product and there has to be agreed-upon procedures to follow so that the code produced has integrity and doesn’t accidently get regressed. Nothing in my previous education or experience prepared me for this complexity and procedures challenges. Fortunately, most of the developers had been developing in this environment for some time and understood the pitfalls.
Packaging and Distribution
Packaging of this product, actually it was three different product features, was organized as SYSMODs to be installed with SMP/E. A team member built the SMP definitions and tested the installation of the product—each step for three features—using the installation manual. After this proved successful, the features were sent to the distribution center where they built the actual products on the actual media (at the time, tape cartridge) and the media was sent to us so us so we could test it just like a customer would in their own IT environment. It now seems obvious that we would have to do all this testing but at the time it was a huge struggle to get it done in time for the release.
Marketing and Sales Support
In parallel to the development of the three product features, we were communicating with the marketing team and figuring out how we would handle sale support. For marketing, we helped build a set of required collateral like FAQs, presentations and descriptive papers. Templates were supplied to us, which helped and provided some content boundaries. For sales support, we agreed to conduct face-to-face training of the regional sales and support people from around the world and they would provide the support in the regions. That model worked well because there was great regional interest but it was challenging to find funding to fly people to the US and put them up for a week. Finding time to create engaging educational materials at the end of the development cycle was tough. A time-management and skill challenge.
A Major Feeling of Accomplishment
As I look back on it, it was a minor miracle that we got it done. Planning and design was much more complex than I anticipated. Development and testing was also very challenging. I wrote some code from a few of the line items and all I could do was put a sign on my door asking not to be disturbed while I was coding and testing during the day and then I would do my other job at night. Packaging and distribution wasn’t difficult but it was time consuming. The skills were specialized so we had to wait for our “SMP/E guy” to be available to help. Marketing and sales support was fun but we learned that developers don’t necessarily make good teachers. Effective teaching takes special skills and it’s often an area where programmers don’t frequently step.
There’s a lot that can’t be taught in school. It’s not the job of a university to do job training. University life is about developing the mind and the person but not necessarily job-specific skills that will be needed at a bank or insurance company. It’s reasonable to expect students to be exposed to many IT topics and to gain real skills. It’s also a good idea to have some work-study opportunities in IT. The challenges I explored in these six posts on “things they didn’t teach me in school” are more about the amazing challenges of working in IT for diverse companies than they were about the shortcoming of traditional education. Learning and experience are to developed and nurtured through an entire career.
Next Week
Next week, I’ll start a new series where I explore software management. You might think of this as system, network, application and cloud management, but definitions and practices are changing and expanding.