My viewpoint is that the retraining programs that currently exist need to be drastically changed in order to improve the quality of delivered software.
In the prehistory of software development, say the 1960’s and 1970’s, companies typically had extensive training programs for new hires. These training programs covered not only the syntax of the programming languages used, but also covered the details of the development process to be followed and the deliverables that were expected. On completion of these training programs (which in the UK were typically 10-20 weeks long), the trainee programmers and systems analysts were assigned a mentor within an existing project team whose role was to give the trainee appropriate assignments to allow them to develop and improve.
By the time that the 1980’s arrived, this type of induction course was a thing of the past and "on the job" training was in vogue, occasionally supplemented by a short course on language syntax or a specific technique. In principle this should have worked since Computer Science graduates were available from universities and various retraining programs were turning out programmers and systems analysts.
Unfortunately what was missed in this was the importance of ensuring that all developers had a common grounding in and understanding of the local development process and standards. At the same time the emphasis also changed from hiring experienced generalists who understood the entire process to narrow specialists who understood one aspect of the overall process. I think that this was a major mistake, and that the effects of this mistake are starting to become evident in projects
Effectively (or rather ineffectively) our industry went from a model based on apprenticeship and craftsmanship to the industrial division of labor without putting into place the standardized tools and practices needed to support an industrial model. At the same time, we had to cope with an explosion of different technologies, it is no wonder that the perception of systems is that they are less stable than they used to be. They may have a graphical user interface and lots of eye candy, but they have poor usability and are buggy.
Is there a light at the end of the tunnel? I think so (and it’s not the headlight of the approaching train). Although standardized processes and the division of labor may be possible in software development, lightweight development processes have arisen during the 1990’s that use generalist developers and partition the workload by features not skillset. The "Borland Software Craftsmanship" approach as documented by Jim Coplien, SCRUM and eXtreme Programming are the better known examples of this type of approach. Similarly the Open Source world rarely separates the tasks of design and programming.
Unfortunately however, the institutions providing software training have not caught up with this trend. There are very few places providing effective training and retraining programs for developers.
University degree programs are doing a good job, but due to the limitations of the academic structure, teamwork, sharing and reuse are not the norm. The role of the Universities is to provide education in Computer Science and Software Engineering, such that their graduates are able to move the state of the art forward. In the process of gaining their degree, many students do in fact become effective individual developers, but they get little practice in the long haul teamwork required to support great software products.
The industrial short course providers could be part of the solution, but only
if they ground their material and content in the larger overall context of the
development process. There also needs to be a much greater emphasis on the interconnectedness
of the various techniques and practices. For example it is very rare to see
a Java or C++ course that makes effective use of the UML in presenting design
specifications. Similarly, teamwork and the need for standards and process are
hardly ever mentioned.
Another part of the solution lies with the Continuing Education side of Universities
and Colleges. Programs have been put together that attempt to mimic the older
company training programs, but with a few rare exceptions, they have all got
lost in the syntax of the technologies and fail to deliver what is really needed
by industry. Many programs cover far too many different tools without providing
depth in anything (In the words of one participant "after covering loops
in Visual Basic, C, Powerbuilder and C++, we didn’t really need to spend
another day on loops in the Java course") .
I feel a large part of the solution lies with the trainers and mentors who work in our industry. We need to start seeing the simple "toy" problems that we give students as a major impediment to them becoming effective developers. Real world systems are different because there is never a single solution, there are always many different solutions, each with different implications and tradeoffs. Just as humans learn to write after they have learned to read, in the early stages developers should read more code than they write.
In many ways I was fortunate when I started my career in software development. After attending a 20 week retraining program taught by an old school systems analyst, I worked in maintenance doing mainly enhancement and bugfixes for the few years. As a result, there was lots of code to be read and understood before I could make my changes. Not all of the code I read was good, but even my untutored eye could soon spot the good code amidst the rest of the spaghetti code. Looking back on it, a lot of that old code really needed refactoring in a big way:-)
Early experience with these ideas has so far been good. I have modified three of my courses that I teach commercially and as part of the University of Calgary Continuing Education programs and the feedback from Industry has been good.
The best feedback to date has been for an "Effective Coding and Testing" course that in 5 days takes teams of participants from a very vague idea for a system to a tested mini-application. Using Use Cases, the UML, JUnit or CppUnit and short cycle incremental development, participants get an experience of what it is like to work in a team using a defined process and standards.
In my "Java for Developers" course, we start by reading over and understanding the JUnit testing framework produced by Erich Gamma and Kent Beck (after all if those guys don’t produce good code, what hope is there for the rest of us?) That code then provides a basis for the discussion about what is good code and how do we test it.
Lastly I converted my "OO Development using UML" course into "OO Development using UML and Java" because of the number of people I found that couldn’t make the leap from class and interaction diagrams into source code. This course also uses JUnit to ensure that the code is unit tested, and to provide an exercise in reverse engineering code into interaction and class diagrams.
The hardest part of about these courses has been the shift from Instructor as deliverer of content to Instructor as practical coach. It took a while before I was really comfortable with the idea that my role as the instructor was to provide appropriate feedback as participants work through the course long case study. Providing access to the content is easy, there are many good books on the market now, the challenge is in letting participants learn at a deep level that allows them to continue improving long after the course has completed.
The last 5 years spent mentoring and training for companies transitioning into Object technology.
"THE TIDE THAT QUALITY MUST TURN IN EDUCATION" R.G.Dromey, Software Quality Institute, Griffith University
"The Pragmatic Programmer" Hunt and Thomas
"Journey of the Software Professional" Luke Hohmann
Pete McBreen, pete@mcbreen.ab.ca