As a developer and Tech leader, I've always emphasized the following:
- Function: The application MUST meet the needs of the customer. Additionally it should meet modern day UI standards for a clean, crisp, and responsive UI, and make obvious what steps a user must take to complete their objectives.
- Correctness: An application must collect & provide correct information to the user. It is correct & slow, it can be made faster. If it's fast, but incorrect, it may be difficult or impossible to make "correct".
- Minimize Technical Debt: Technical Debt is a huge, often hidden, financial burden on companies & software teams. Open Source libraries that are embedded in applications can go out of maintenance, or worse, disappear forever. They may have hidden security flaws that require massive remediation efforts when discovered, or require emergency upgrades to entire applications that then require a massive testing effort. New systems should never be built using frameworks that represent built-in technical debt. One example comes to mind: at one company, new applications were being built with the .NET framework. There's nothing "wrong" with the .NET Framework. But MS is no longer improving it. They've committed only to "security" upgrades. New NuGet packages that an application might need may see no value in providing .NET Framework compatibility. This is technical debt built-in to a new application.
- Reduce the Lines Of Code: Every line of code is a potential bug. Reducing the lines of code reduces the potential bugs. This requires aggressive & serious refactoring, as well as adherence to SOLID & DRY principles.
- Re-usability: Again, smaller code, following SOLID & DRY principles, usually results in more re-usable code. I've written several NuGet packages at prior companies that were stored in private NuGet libraries & used by multiple in-house teams for Authentication, Logging, etc.
- "Clean Architecture": While I've designed applications in the past using Domain Driven Design, I've been researching "Clean Architecture". It's somewhat of an inversion of Domain Driven Design, but has specific benefits for testability & Dependency Injection..
- Mentoring: Many years ago, a more senior colleague of mine stated that a major responsibility of a Sr. Developer was to teach others how to be better developers. I've taken that to heart. If you read my recommendations on Linked In, you see that most of them mention my collaborative & mentoring approach to working in teams. In many of my consulting engagements, training others to use .NET was an integral part of the engagement.
