Internal tools only require the critical path
I always try to remember how easy developing internal tools is. We have a captured audience. We can quickly deploy fixes. We are largely independent of rigid processes in place to support the customer base.
Our job, as Tech Artists and tools programmers, is easy. Well, easier, at least.
I think it comes down to this: Dev tools only require the critical path to work. We don’t have to worry about security. We don’t have to worry about cheating. We don’t have to worry about billing. We don’t have to worry about making optimizations that make our code more confusing. We don’t have to worry about the one thousand little things you should if you are developing an external product.
Remember this, and you will be a more effective Tech Artist and Tools Programmer, because you will spend your time where it matters. Forget this, and you will waste your time working on and worrying about things that provide no values, manufacturing theoretical problems.
Ensure the critical path works at all times. At all times. Ensure people are directed down the critical path through intuitive design and documentation. Restrict them from veering off the critical path where you must. Ensure if they veer off your tool’s critical path, it does not cause havoc and they can pick the path back up.
On the flip side, make sure you are being ambitious. Experiment. Have fun. Don’t be afraid to try new things. You are developing internal tools, you have that freedom. Try a new framework. Use a different issue tracker. Introduce a new coding or development style. Install a new tool. Your life is easy because you are working on non-critical software (that’s the truth of the matter, sorry folks, that’s why so many of us have shitty tools). Make up for that lack of prestige by having more fun at work.
Just keep the critical path in mind.
good post. But don’t forget about us outsourcers though. We love it when you develop your tools as if they were (at least a little bit) for an external client. Ideally you want to ask yourself “is there a chance we will give this tool to a 3rd party?”.
Cheating, unfortunately does happen – some people just like shortcuts. That’s where QA comes in, or your tool, so it prevents cheating right away.
Security – many outsourcers have different clients and enforce stricter security than their clients. your tools should play along that, or we have to send them back, or spend time with your TA troubleshooting (not good for both parties).
Still, the lengths you have to go to are still way below anything if you’re billing an external client for it. So yes, do experiment!