What should a Professor Teach?

January 31st, 2006

Recently I wrote about Real World Software Development versus College Labs and suggested that instead of only teaching the proper methods of developing software that real world scenarios should be also simulated in the labs. I believe that students should be taught what is the current understanding of modern software development, but once a new graduate joins a team after college there are going to many factors in the development process which were not considered in a college lab. These students must be given the tools to cope with legacy systems...

Right now in school I am sure that Agile is now a major piece to the curriculum with unit tests and test driven development. But what we must keep in mind is that these are fairly new additions to the software developers toolkit when you have a legacy system going back more than 20 years. At the recent WJUG meeting I joked that unit testing did not exist until JUnit. But seriously, unit testing only took off when the tools and platform made it possible with minimal effort, and JUnit and Java made that possible with a reflection and a simple naming convention. This means that software created previous to the rise in popularity of JUnit was created without all of these unit tests.

If you were to see a list of features and requirements for a legacy system and was tasked with making a few updates you may be overwhelmed or underestimate the damage you could do with even the most basic change. Large systems can be fragile and without unit tests to verify conformance to business rules or existing behavior it is very risky. Without automated unit tests and a continuous integration environment you must manually test every change, possibly involving a test group of business users. And scheduling these people to carry out the quality assurance process faithfully can be a full-time job in its own.

So instead of butting heads on getting Joe Business User to comply with your QA requirements you may eventually decide to implement a plan to add unit testing code to the legacy system to minimize risk and speed up development. And this is where I feel academics would do well to augment the curriculum. It is always a good idea add quality controls to the software development process, but at what cost? And how do you justify that cost to management? How do you measure the value?

What I have learned is you may have to resort to a bit of personal initiative to implement improvements as well as put things into financial terms. Talking in terms of what is ideal for software development does not win over management. But if you can project that requiring 3 business owners to put in 20 hours of QA time with each software release versus you doing 40 hours of work once to implement thorough unit tests you may make more headway and add measurable value through your work.

A couple of years back I read about Design Debt which puts software development concepts in the terms of financials. Say you take out a loan at a high interest rate to pay for a service which will allow you to meet an aggressive deadline. Each month you make payments on that loan at the high rate, but eventually you refinance that loan and reduce the overhead of that loan. When compared to software development, the refinancing is the same as code refactoring. You can build an application quickly to meet an aggressive deadline but you will pay for it over time due to increased overhead. As you refactor the code to simplify it you can reduce that overhead and bring down the Design Debt of the software.

When you can put software development in such terms when working with management you will find you are able to do what you learned in school while also satisfying your employers business needs.

Let's do the math on the code refactoring. Take the 3 business owners who must give 20 hours of their time for every application deployment for proper QA testing. Assume that is at a cost of $100 an hour, although it likely higher. That gives you $6,000 in overhead. If you are a recent college grad your salary will be much lower than a manager and your time may be estimated at $50 an hour. If you put in 40 hours to add quality controls through unit tests and build automation you will cost the company $2,000. The impact of that cost is the important part. By implementing those unit tests you have raised confidence in the fresh releases which will allow you to reduce the amount of tests the business owners must run manually. For that one time cost of $2,000 you have reduced a recurring cost of $6,000. The unit tests are allowing you to catch bugs during the development process and correct them before it reaches the testing phase. The 3 users may only have to spend 4 hours briefly reviewing the new release with fewer bugs which need correction. The overhead is now just $1,200. And if there is 1 release every quarter you have saved the company almost $20,000. (Be sure to mention that in your annual review!)

The unit tests will also allow you to speed up development which may mean you will be able to implement more features with each release. That also adds value to your work which was not possible without the unit tests.

A college grad may know exactly how to create software in the best way possible, but without being able to justify the work necessary to reach their goals all of that education can go to waste. With this way of thinking about software development added to the curriculum it will better prepare students to be successful in their careers. I feel this is what professors should be teaching.

Comments are closed.