Editor's Note: Venkat Subramaniam (above) is keynoting at The Path to Agility on May 20th & 21st at the Ohio Union in Columbus. He will also be a featured guest at After the PATH, the reception event following the conference on May 21st. 

 
Venkat Subramaniam: Advancing Agile Education
By Terreece Clarke, May 14th, 2014

Venkat Subramaniam, author of “Practices of an Agile Developer” and “Functional Programming in Java,” founder of Agile Developer, Inc., and an instructional professor at the University of Houston, is bringing his thoughts to The Path to Agility conference on May 20th and 21st at The Ohio Union in Columbus. Subramaniam has spent 20 years teaching and helping others around the world, which is a labor of love he discovered early in his career.

“Here, I would be working for 10 hours for a corporation, getting...the salary of a professional, then I would go in and teach, getting really paid nothing and it was much more fulfilling,” he said.

Subramaniam began stay behind to talk to students for many hours, listening to their problems and ideas about programming, life, etc., and realized that interacting with the students and teaching was what he really wanted to do. After 5 or 6 years he decided to quit his corporate job and began teaching courses in the industry and he hasn’t looked back.

“It’s a combination of figuring out what you really enjoy doing and making a decent living out of it,” Subramaniam said. “Some people run after money, some people run after fame...one of the things I tell others is, ‘if you asked me the color my ceiling in my bedroom of my house, I have to tell you I don’t know. And the reason is, there is not a single day, not a single day, that I have been in bed looking at my ceiling. At the very first sign of being awake I am jumping out the bed working. To me, the day I don’t want to get up from the bed and do this is the first sign I’m finished. Fortunately it has not happened in the last 20 years.”

Facing the Fear of Failure

One of the issues Subramaniam said he still encounters in programming today is a lot of programmers take to design patterns. Introduced in 1994-1995, the idea caught on like wildfire. One of the problems Subramaniam points to (with the steadfast adherence to design patterns) is that design becomes a cookie-cutter approach and programmers try to fit everything into an existing design pattern, or will apply the wrong design pattern, creating complexity in code.

“In doing this, we have forgotten a very important thing,” he said. “Human beings are spontaneous and creative. That is the beauty of coming up with innovations and design. [Programmers should] relax, sit down and let it happen. But it is easy to see why people fall back into well-known methods -- they don’t want to take the risk. We have created a society where people fear failure.”

He suggests that the best way to learn design is to create it and be critiqued. His students are designing and making mistakes over and over until midway through the semester, when they discover what they are designing and thinking through the principles Subramaniam would tell them to apply.

“They begin to systematically think about design and apply their own ideas. It’s what we need to do in the corporate world as well. Give an opportunity for people to quickly make mistakes and try out ideas and learn from it. I think that’s an invaluable tool for what it can teach us,” he said.

Making Mistakes, Profitably

How does time spent on risk taking and small failures fall in line with what drives corporations - the bottom dollar?

“We want to make money, we want to sell products that are extremely valuable. The way we can do this is by quickly releasing products. One problem with the world quickly...we can try to optimize locally saying, ‘I want to penny pinch on every single activity,’ but the in process we may lose money globally,” he said. “Instead, if we increase the quality of how software is being developed...both in terms of of design and code, it is going to cost slightly more, but it is going to decrease the maintenance cost and debugging cost to a great extent.”

“By compromising a little on local optimization, we gain much more on global optimization, Subramaniam said. “And good companies have figured this out -- companies like Apple, Toyota and Google give a great amount of leverage to the developers and the companies win big.”

Companies who don’t do this, he said, end up squeezing at the bottom and suffering major problems. He cited a company he knows that is currently wasting millions in bug fixes and is in trouble with clients who have litigation against them because they created software they cannot adequately support.

“Agile development isn’t just about running really fast,” Subramaniam said. “It’s about running reasonably fast in the right direction.”

What's Next for Agile

When looking ahead at what’s next for Agile, Subramaniam points to two areas he sees as vitally important.

“One of the challenges today is people have taken Agile and made it into a commodity,” he said. “They are trying to put labels on it and pin down a certain set of practices and be prescriptive about it. Instead we need to ask what Agile really is? To me, it is succeeding in what we do, using a series of feedback loops. One of the key components of that is adaptive planning.”

“I work with a large number of big organizations. When I walk in, they are eager to tell me, ‘Oh Venkat, we are Agile!’ And I always say, ‘I’m so glad we’ve got that out the way. Now, what are you really doing?’ They were eager to put a label on what they are doing, but are not really Agile. They aren’t focusing on adaptive planning. People are still planning everything ahead and sticking to those plans. That’s not Agile development.”

Another thing Subramaniam would like to see is an increase in automated testing. He called it a crisis in the field. He said that there are three kinds of companies right now: companies who are not doing any automated testing, those who do automated testing at the wrong level ( at the UI level, a practice that Subramaniam calls “a pathway to hell”) and companies who have automatic testing at the lower level, fewer tests at the top level. Only a few organizations are getting it right.