Ask HN: Resources on Designing and Improving Internal Tooling
Dealing with a bevy of pre 2020 internal only software, and looking for blogs and books, on what patterns help to successfully improve them? Looking beyond the classic "Strangler Fig Method", and Belotti's "Kill It With Fire".
1 comments
Internal tooling is often horrible because nobody takes it seriously. It is often not funded and therefore not part of your annual evaluation (any part the matters to anybody who reads employee evaluations). That is a culture problem and just feeds the "Invented Here Syndrome" so common with modern corporate software practice.
The solution is to establish a standards of practice and appoint somebody to own it. This means you need to get your boss and their boss involved and achieve leadership buy in. This is the very first step, because if you cannot achieve this nothing else matters. Dead on arrival.
Second, write a policy defining the standards of practice. That policy will include things like:
* Where will internal tools be saved or stored?
* What is expected in the documentation of each tool.
* List required test automation criteria. If a given internal tool cannot be tested by clicking a few buttons... its only a vanity trophy nobody else will maintain. Don't be shy about this.
* Every document of every internal tool should start with a purpose statement. What problem does the tool solve? This is business problem that saves time or money... not a technical problem.
* Document API criteria for both inputs and outputs of the given tools.
* Describe languages, tools, build steps, and all that other nerd stuff to execute it. Don't make people guess. This sounds import, but is actually the least import part of tool documentation. If this part sucks send it back to the developer/team for revision.
Your policy document must be signed by a senior executive so that it becomes law. Expect your policy documentation to mature over time. With that maturity will come consolidation of practice. Your team will find and describe standards for describing, executing, and testing things in the fewest ways and least effort as possible.
Finally, there should be a catalog of these tools. That catalog is just another set of documentation, but it needs to be fully automated from each tool's documentation to describe last update (date/time), purpose statement, and any other criteria people might want to sort/filter by.
As for old tools you need to perform an inventory and determine what are people willing to maintain. Everything else needs to be eliminated or archived away from active tools. Be aggressive about this. If there is a tool out there in use but long since out of maintenance get some leadership involved to either kill it or impose somebody to take ownership.
The solution is to establish a standards of practice and appoint somebody to own it. This means you need to get your boss and their boss involved and achieve leadership buy in. This is the very first step, because if you cannot achieve this nothing else matters. Dead on arrival.
Second, write a policy defining the standards of practice. That policy will include things like:
* Where will internal tools be saved or stored?
* What is expected in the documentation of each tool.
* List required test automation criteria. If a given internal tool cannot be tested by clicking a few buttons... its only a vanity trophy nobody else will maintain. Don't be shy about this.
* Every document of every internal tool should start with a purpose statement. What problem does the tool solve? This is business problem that saves time or money... not a technical problem.
* Document API criteria for both inputs and outputs of the given tools.
* Describe languages, tools, build steps, and all that other nerd stuff to execute it. Don't make people guess. This sounds import, but is actually the least import part of tool documentation. If this part sucks send it back to the developer/team for revision.
Your policy document must be signed by a senior executive so that it becomes law. Expect your policy documentation to mature over time. With that maturity will come consolidation of practice. Your team will find and describe standards for describing, executing, and testing things in the fewest ways and least effort as possible.
Finally, there should be a catalog of these tools. That catalog is just another set of documentation, but it needs to be fully automated from each tool's documentation to describe last update (date/time), purpose statement, and any other criteria people might want to sort/filter by.
As for old tools you need to perform an inventory and determine what are people willing to maintain. Everything else needs to be eliminated or archived away from active tools. Be aggressive about this. If there is a tool out there in use but long since out of maintenance get some leadership involved to either kill it or impose somebody to take ownership.