"The Best Programming Advice I Ever Got" with Jeremy Likness
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Name:
Jeremy Likness
Job Experience:
I’ve been using computers since I started tinkering with a TI-99 4/A in 1981. From there I moved to the Commodore 64 and eventually to Windows and the Microsoft stack. I’ve been programming with the Microsoft stack for two decades now, with the last fifteen years focused on building enterprise web-based line of business applications. I’ve worked in multiple verticals including insurance, healthcare, financial, supply chain, and even mobile device management. My job title has ranged from developer to Director of IT and I’ve worked both as an independent contractor and the single resource on a project to a development manager over a large team of dozens of developers. I’ve been developing for and writing about Windows 8 since the Developer Preview was released in September of 2011.
Most Notable Achievement:
I’m very excited about the success of the object-oriented database I created called Sterling. When I began developing Silverlight business applications several years ago, there was no database solution so I built a lightweight tool to fill the gap. When the Windows Phone was released, it turned out only a few tweaks were needed to update Sterling to run on the phone. Since then it has had thousands of downloads and been integrated into many published applications for both the phone and using Silverlight in general.
Most Frequently Used Programming Language:
C#
Advice:
The best programming advice that I ever received can be summarized by the acronym YAGNI, or “You Aren’t Gonna Need It.” This is a very tough principle for many developers to follow because it is easy to get caught up in the excitement of building a rich architecture and providing clever solutions to problems. I’ve met many software engineers who focus on heads-down coding and shy away from management or taking on larger responsibilities in the business. That is perfectly fine, but I am glad that I had the opportunity to both own my own business as well as hold executive level positions so that I could begin to understand the bigger business picture and specifically the fact that software is never about the software. Every company is selling a solution and often software is either the whole solution, or a component of the solution. What drives profits is shipping software that works. While this may upset many developers to hear, the end user of a product doesn’t care how well architected the underlying code is or if there was a really elegant, clever solution to a problem. They want a product that is easy to use and works (although a quality architecture often helps ensure this).
Simplicity is key to building great software and I believe many developers create solutions that are overly complex. It’s easy get away with when you are running a small team, but when the development team (and typically the product itself) get larger, simplicity becomes more important. It’s not just about a clever solution, but one that is easy to read, learn, and understand. My test of architecture used to be how well it solved a problem, but now it’s also about how easy it is to learn and understand, and how much more quickly it enables a new developer to get up and running. Unfortunately, some architectures are so complex they actually slow down new developers and that’s not a good thing.
YAGNI pulls this together and cautions us against trying to build for every contingency. It is easy to get stuck in a cycle of building architecture for months before having anything tangible for the customer to use. The customer will always react to the application when they are able to use it the first time, and that often leads to changes and refactoring. In my experience I’ve found it’s far easier to add new pieces of architecture to support new demands than to incorrectly forecast those demands and have to refactor an existing code base. My advice to developers is to focus on what you know and need, not on what you might need or what might happen, because there’s a good chance you aren’t going to need it. Instead of trying to build an architecture that handles every possible scenario, build software to support the specific scenarios you know about. As the software grows, you have the opportunity to identify areas where solutions are repeated and refactor those to a common architecture that can be reused. In the end, I’ve found this type of architecture that grows as the result of the code is far easier to use and maintain than a heavy up-front architecture that attempts to address every potential problem that may come down the line. This approach also tends to be kinder to the bottom line, and in the end that’s what business is about.