Ask HN: Resources on how to build internal/enterprise tools?
5 comments
Hi, Have some experience in this area. As we often build apps that are used internally for customers.
What @selmet said hits the nail on the head
"From my experience, requirements don't come from bottom but it should. Initiator is almost always manager who might have some idea or vision but it's not right originator."
Having said that, the same principals that apply for "consumer apps" would apply to internal enterprise tools.
Here is some of what i do when consulting:
- Start with "what is the problem you are trying to solve?, what are you trying to achieve?"
- Is the envisioned tool/app/software going to actually solve this problem?
- How can we get more data to validate or disprove this?
- What are the minimum set of features needed (MVP) to get it in front of users?
- If the sponsor/initiator is not the actual person the software is targeted or is far removed from the actual problem. Speak to the actual users on the ground, the people who are trying to solve this every day. Effectively do customer dev with them (from startup world)
- Depending on the organization, you may find some resistance if you focus on user needs. This is usually driven by "bigger pay checks = better opinions" type thinking. What you need to do here is get people to understand the problem, and how the features being added are specifically towards solving them and nothing else.
The knowledge gained, and paradigm shift you get having been in a startup, even a failed one is tremendously useful. You will find when you get into more traditional enterprise you are thinking different to most people there, you see things in a different light. Always looking for the quickest path to validate, and ensure you are heading in the right direction.
What @selmet said hits the nail on the head
"From my experience, requirements don't come from bottom but it should. Initiator is almost always manager who might have some idea or vision but it's not right originator."
Having said that, the same principals that apply for "consumer apps" would apply to internal enterprise tools.
Here is some of what i do when consulting:
- Start with "what is the problem you are trying to solve?, what are you trying to achieve?"
- Is the envisioned tool/app/software going to actually solve this problem?
- How can we get more data to validate or disprove this?
- What are the minimum set of features needed (MVP) to get it in front of users?
- If the sponsor/initiator is not the actual person the software is targeted or is far removed from the actual problem. Speak to the actual users on the ground, the people who are trying to solve this every day. Effectively do customer dev with them (from startup world)
- Depending on the organization, you may find some resistance if you focus on user needs. This is usually driven by "bigger pay checks = better opinions" type thinking. What you need to do here is get people to understand the problem, and how the features being added are specifically towards solving them and nothing else.
The knowledge gained, and paradigm shift you get having been in a startup, even a failed one is tremendously useful. You will find when you get into more traditional enterprise you are thinking different to most people there, you see things in a different light. Always looking for the quickest path to validate, and ensure you are heading in the right direction.
I find building toward ease data entry and access - not what looks pretty
Make entry as easy as possible text entry for times & dates - with a tooltip calendar, (unnecessary pop-up lists are a pain for anything when entering bunches of records.) Consider using chekboxes and radio lists for selection over popuplists sometimes they provide visual cues easier then reading or expanding a popup.
Reduce complex multi-table entry forms to one screen, same with displaying data... Make it so in reports where you might need to correct entry staff can click right to record edit instead of having to back out, etc.
Try to make every bit of data collected usable, don't just have a "office hours" field have a schedule entry so you can draw on the data - down the road someone will say, I saw you collect X, can we use that to do Y? Be prepared to say "no problem."
Make entry as easy as possible text entry for times & dates - with a tooltip calendar, (unnecessary pop-up lists are a pain for anything when entering bunches of records.) Consider using chekboxes and radio lists for selection over popuplists sometimes they provide visual cues easier then reading or expanding a popup.
Reduce complex multi-table entry forms to one screen, same with displaying data... Make it so in reports where you might need to correct entry staff can click right to record edit instead of having to back out, etc.
Try to make every bit of data collected usable, don't just have a "office hours" field have a schedule entry so you can draw on the data - down the road someone will say, I saw you collect X, can we use that to do Y? Be prepared to say "no problem."
Another big thing on internal/enterprise apps is access and administrative tools. As a lot of people are working on your data some only have limited program access, or access to only certain datasets... also others can check on activity of how the data is entered/accessed/updated, might also be some sort of job logging going on.
"strategies on building these tools"
The mechanics of actually building stuff, or the part where you want to get paid for it? Could you expand on that a little?
The mechanics of actually building stuff, or the part where you want to get paid for it? Could you expand on that a little?
From my experience, requirements don't come from bottom but it should. Initiator is almost always manager who might have some idea or vision but it's not right originator. And this is the main issue. He is trying to remove outward manifestation not root cause. Employees are always struggling with deeper issues than manager is trying to solve.
Practical example: I am working with huge amount of data about customer's network infrastructure. Every item (device/contract/ticket) has own web page. There is huge items with wrong or dummy data. If I need report, verify and amend certain data i can't do it via bulk requests or automatically. Our application doesn't have such interface, we don't have API, we don't have CLI. I did talk to architect and he said me...no, we don't have it, and you are the first one who asked for it. Nobody need it. So sorry but no.
Another example: internal tool, have some features but are wrongly implemented. I reported that it doesn't work as expected. I received reply that nobody use it, so there is no chance to get resource for fix and improvement.
And another one...manager bring idea with time saving and required new internal tool which will do automatically sign-in to all day-to-day tools. It saved almost 5 minutes. But after password change it very often locked users account. In total it wasted few hours of raising incident with internal IT.
And I have lot of similar experiences. So from my point of view here are key features for corporate internal tools:
1) If tool or function doesn't work - hide it or remove it
2) If documentation is available - do it properly. Have some documents with terminology explanation. Explain purpose and dependency between fields. Also explain what is mandatory and why. This is whole story how can proper documentation save your time and money. Everybody need to understand what they use and why they have to fill field A, B, C and optionally D. You can save a lot of time, money and issues, especially with newcomers. This documentation can be studied at any time during future work. You can avoid misinterpretation from older colleague etc.
3) If tools are developed always talk to end user not only with manager. Ask 5 times why should we solve this? Isn't the real issue somewhere else?
4) Internal tools always needs to be supported from management. Otherwise is very small chance that your effort will be appreciated.
5) If you create tool have CLI version. GIU is some kind of protection against stupidity but it also restrict improvement and speedup of whole process.
6) If you work with data, use standardized format like csv, xml or json. Same format needs to be used for import and export. If other internal tools use csv don't use xml or json and vice-versa.
7) Other internal tools have to be able work with same format. Export from tool A have to be applicable (or with small amendment, no more than several clicks/removal and copy-paste actions) into tool B. So your format what is standardized for other tools.
8) Don't use insane level of nested features and choices. Something like Audit-> Results -> Failed/Succeeded -> Details/Settings/Re-run -> (Details) Result/Rule/Config/History -> (Result part) Output: " Filed X, Y, Z wasn't find in config" ... and you are thinking wtf? Why? And you have to open different window and verify it manually. I need to know what was found and why it didn't match. Very often is due to wrong regexp pattern, but it take almost 30 minutes to verify all possible paths and find root cause.
9) Use universally applicable language/environment. From my experience you create something which works at computer/server A but it will fail on computer/server B.
And there are tons of other issues I dont remember. Some of them are technical (software/system/hardware) some of them are social - people/management. I would say social issues is much harder to overcome than technical. Social issues are also more important, because if it fail to solve, entire project/tool can be damaged. Technical issues can be solved almost every time. If solution A doesn't work we can create B, but we always solve it.
Practical example: I am working with huge amount of data about customer's network infrastructure. Every item (device/contract/ticket) has own web page. There is huge items with wrong or dummy data. If I need report, verify and amend certain data i can't do it via bulk requests or automatically. Our application doesn't have such interface, we don't have API, we don't have CLI. I did talk to architect and he said me...no, we don't have it, and you are the first one who asked for it. Nobody need it. So sorry but no.
Another example: internal tool, have some features but are wrongly implemented. I reported that it doesn't work as expected. I received reply that nobody use it, so there is no chance to get resource for fix and improvement.
And another one...manager bring idea with time saving and required new internal tool which will do automatically sign-in to all day-to-day tools. It saved almost 5 minutes. But after password change it very often locked users account. In total it wasted few hours of raising incident with internal IT.
And I have lot of similar experiences. So from my point of view here are key features for corporate internal tools:
1) If tool or function doesn't work - hide it or remove it
2) If documentation is available - do it properly. Have some documents with terminology explanation. Explain purpose and dependency between fields. Also explain what is mandatory and why. This is whole story how can proper documentation save your time and money. Everybody need to understand what they use and why they have to fill field A, B, C and optionally D. You can save a lot of time, money and issues, especially with newcomers. This documentation can be studied at any time during future work. You can avoid misinterpretation from older colleague etc.
3) If tools are developed always talk to end user not only with manager. Ask 5 times why should we solve this? Isn't the real issue somewhere else?
4) Internal tools always needs to be supported from management. Otherwise is very small chance that your effort will be appreciated.
5) If you create tool have CLI version. GIU is some kind of protection against stupidity but it also restrict improvement and speedup of whole process.
6) If you work with data, use standardized format like csv, xml or json. Same format needs to be used for import and export. If other internal tools use csv don't use xml or json and vice-versa.
7) Other internal tools have to be able work with same format. Export from tool A have to be applicable (or with small amendment, no more than several clicks/removal and copy-paste actions) into tool B. So your format what is standardized for other tools.
8) Don't use insane level of nested features and choices. Something like Audit-> Results -> Failed/Succeeded -> Details/Settings/Re-run -> (Details) Result/Rule/Config/History -> (Result part) Output: " Filed X, Y, Z wasn't find in config" ... and you are thinking wtf? Why? And you have to open different window and verify it manually. I need to know what was found and why it didn't match. Very often is due to wrong regexp pattern, but it take almost 30 minutes to verify all possible paths and find root cause.
9) Use universally applicable language/environment. From my experience you create something which works at computer/server A but it will fail on computer/server B.
And there are tons of other issues I dont remember. Some of them are technical (software/system/hardware) some of them are social - people/management. I would say social issues is much harder to overcome than technical. Social issues are also more important, because if it fail to solve, entire project/tool can be damaged. Technical issues can be solved almost every time. If solution A doesn't work we can create B, but we always solve it.
It seems like there is a lot of knowledge out there, as every company I have worked for has teams for internal tooling -- but very little public or communal knowledge.
Perhaps it's because the problem isn't as "sexy" as consumer tooling and products?