There is nearly universal consensus on the statement/claim that software development should be focused on user needs and overall happiness. If nobody is using the code you write, it is by definition useless. Over the last few decades, many of the major strides and shifts in our industry have been centered around this basic idea of making the user the focus of software development (e.g Agile).
Software “engineering” however, differs from every other kind of engineering in one specific way, it is mostly a living product. There is generally no “completed” state. It is constantly being extended and modified. As such, written software generally has 2 sets of users that are equally important:
Interface consumers (Traditional “end users”) - these are the users that are going to consume the features of the software
Implementation consumers - engineers that will be expected consume the code written in order to modify/extend the software and deliver updates to 1 above
You can’t focus on the former and ignore the latter, because when the latter finds your system difficult to use, it directly affects the quality delivered to the former.
To this point, as an industry we have implicitly recognized the second set of users and made changes to serve them (think automated tests, documentation etc etc), but thus far it has primarily just been done under the banner of “maintainability”.
There is significant value to explicitly calling them out as not just users, but first class users. Not only does it put the correct level of emphasis on the goal/result, but it also makes clearer what you are trying to achieve when you talk about maintainability.
Most companies track things like NPS to track end user satisfaction. How many have something similar for their software? So many maintainability issues could be avoided/solved by creating a feedback loop with those that maintainability is targeted at - keeping a pulse and how engineers (especially those foreign to the system) feel about navigating your system
No comments:
Post a Comment