The Future of Software: The 3 T's of Great Software
When I give a presentation at a conference, I love to start off with a bold, controversial, and perhaps unbelievable statement. Then I work the rest of the presentation to convince everyone to believe it. Here are some bold statements that got me into a lot of trouble in the past:
- Never use the "private" keyword in Java
- Never use a Java checked exception
- Private clouds are far better than public multi-tenant clouds for enterprise software
On a good day I can get a majority of the people convinced. On one particularly good day I convinced the whole conference room. Or perhaps they just wanted to leave and thought I wouldn't let them go until they backed me. I'll never know for sure, but I'm counting it as a win nonetheless!
In my first post in this series, I started off with this bold statement: we really haven't seen a game changing software advance in the last 15 years. Now that is a pretty controversial statement given that millions of software developers, including myself and many of my friends, have been working very hard for quite a few of those years. Unfortunately, I've come to the conclusion that we are working hard on the wrong technologies and techniques. To address this overarching issue, first of all let's get our priorities straight. I'll briefly discuss the 3 T's of great software, in priority order:
- Talent. Great talent always produces great software. No matter what the technology, no matter what toolset or technique is available or forced upon them, it still comes out great. I wish I could tell you how to create talent but I don't know that you can create it. I believe it is a special gift that some people possess. If you look very carefully, you can find it in the young and the old, in the experienced and the inexperienced. But I can tell you, when you find it, do everything you can to keep it and enjoy every minute of your work with them. In a future post, I'll discuss how to rapidly size up someone's innate software engineering talent.
- Technique. I've seen a lot of techniques, methodologies, methods, and processes. I even published my own method. They appear quite different as an outsider looking in. But when you actually apply the technique in sufficiently large teams of people on sufficiently difficult problems, the differences are not meaningful. The techniques in common are always consistent and successful. When I'm asked to follow a technique, I will pay special attention to those parts of the technique that always work across the spectrum of good software engineering techniques. I will then minimize investment in parts of the technique that are contentious differences among the methodologists. We will address this topic in a future post as well.
- Technology. The actual tools that make it possible to write, package, deploy, debug, and correct software.
Unfortunately in my experience the software industry has a completely backwards set of priorities. They focus on technology first, technique second, and talent last. Most of the books available for purchase are technology books. They teach the quickest path to applying a programming language, software product, or language library to a sample set of problems. Now I'm just as guilty as anyone, I wrote a major portion of a Java library book! You write what people pay to read, and I learned that hard lesson after many rejected book proposals focused on improved software engineering techniques.
Now there are quite a few books on software technique as well. But nowhere near the quantity and depth of material that we have available on software technology. And even worse, the books on software talent are almost nonexistent. There is not much of an audience for how to attract, build, and retain software engineering talent. Most hiring managers list the technologies they need for their project, find people with enough experience in those technologies, and hire them as quickly as they can.
We can and we must do better hiring and talent retention. And even in an agile software development world, we need to pay a lot more attention to technique. I'm betting almost everyone reading this post has heard "we're agile" as an excuse to skip a commonly accepted practice that will almost certainly create severe issues down the road. With that said, almost all the posts in this series will be technology posts and that's just fine by me. I'd say we have a much longer way to go to advance software technology. But I won't promise the technology posts will be pure technology. In almost every presentation and article I've ever authored, I've laced it with technique lessons. A spoonful of technology sugar sure does make the technique medicine go down!
To wrap up this post, I'll throw out another bold statement: code generation is the technology innovation that has always powered great advances in software. Now when you combine that bold statement with my first bold statement, you will see exactly where I'm going with my next post. I hope you enjoy this series and look forward to your feedback and ideas.
Thanks!
Todd Lauinger
Technical Consultant
8 年Quick fix is the way to go where only T that matters is Time. Brooks or Pressman seem to be the authors of past :) Can't wait to read the next instalment.
Product Manager at Dell Technologies
8 年Interesting post, Todd. I completely agree with you on the importance of "Talent". Attitude and ability to work well with a team are more important than technical aptitude. One resource cannot build a complex solution single-handedly. Resources must be able to work well with colleagues who might have differing personalities/opinions in order to meet company goals. In a services organization, this is even more important since there are various cross-functional stakeholders such as project managers and customers. I would rather have a less-skilled resource with a great, flexible attitude than a tech-ninja with a poor attitude; one negative resource can lower the productivity and morale of the entire team.
Research Group Head at Siemens Corporate Technology
8 年Agreed Todd! Technology is the first T that we try to concentrate during interviews and in the process also try to assess the talent and the technique. There are only handful of times we attract the right talent and teach then the technique and technology. While I am sure Talent focus will give us the perfect spirited individual most often than not we do not have the time! So I agree with you, time for a change in priority and create the talent that not just knows what to do, but do it in innovative and lovable ways (Again here I do not agree about the code generation technologies, somehow I felt I learnt more when I was coding using Textpad rather than IntelliJ!).