In development, we all can agree that the user is most important. And what do users love? Features.
It’s reasonable to assume that each of your users will want a new and unique feature at least a few times per year. Product owners guessing at what these features could be can cause backlogs to fill up, and it seems as if no matter how many developers you add to a project, the work just never ends. So to keep each user happy and keep the budget in check, every effort should be spent on making developer time productive to get those features out the door as soon as possible. On this we all can agree.
My proposal is to maximize development time on features. Every day spent on work other than feature development is a day wasted. Focusing only on refactoring code, writing unit tests, and working with a Git-branching strategy will distract from additional feature work. Think about it: Will the user ever know if you used Gitflow or trunk-based development? No.
There are many moments during the day when code is not being written, features are not being developed, and new buttons on a web page for users to click are not showing up on their screens. This time is much better spent with hands-on-keyboard work.
Simplifying development is one way to help make more feature work happen. Starting with a strict rule of “no frameworks” is a good start. If the developers use anything but HTML, CSS, and vanilla JavaScript to create a web app, it becomes overwhelmingly confusing. Time spent learning and understanding trend frameworks could be time spent, for example, building a font-kerning customizer for the customer.
When it comes to the process, if it ain’t broke don’t fix it. While DevOps is primarily about tools, it is also about culture and process. Some ideas around DevOps are really encouraging, like maintaining a backlog that puts highly requested features above bugs. However, other ideas are less ideal. For example, some DevOps proponents suggest forcing software developers and operations to work dangerously close to one another. Distance between these groups is healthy, because of the separation of concerns: one group writes code, another downloads RAM onto servers.
Another idea put out by some radical DevOpsists is centered around monitoring. The energy creating, maintaining, and understanding a monitoring tool could be spent on features. One thing proponents often forget is that if a user calls to report an issue they are running into, it’s a perfect opportunity for them to ask if they liked the last feature that was deployed and if they can think of any new features they might want.
This is why I love Minimum Viable Products. The idea is to create a fully featured product that keeps monitoring, continuous integration, automated tests, code reviews, discussions about security and new technology, and coffee breaks to a minimum. The Minimum amount of time spent on those things while creating a Viable Product is how success happens. Once users see all the features when they are delivered all at once in a new product, that’s when client success and a strong customer experience is achieved.
*Originally written by Jared Porcenaluk from Nebbia Technologies, a New Signature partner.
