"Yes, that was painful, but we've just created a tool for that. Rapid Development FTW."
These words make me shiver. There was a problem / time-consuming activity / knowledge gap & we've created a tool to fix / solve / simplify or just speed things up. It makes sense, doesn't it? People have just showed some creativity & initiative - they've used their brain-power to make actual difference. Isn't it what software engineering is about? What's wrong about that?
You're right, in general I love when devs do that - it's one of the key differences between a great developer (with a true ease of writing code) & a uninspired crafter. And it's perfectly fine as long as the creator is the only one who'll be using this crafted piece of software. Things get complicated when:
- there will be other users
- this piece of software will participate in any process of significant importance (even if it's daily deployment flow)
- it's not a one-shot app, the changes will follow (which is pretty much ... always)
Development itself is easy, it's maintanance that makes things tricky.
Omitting the most simple cases (that appear to be rather sort of simple scripts than full-fledged applications), there are some rules you should never ever break:
-
Each applications is supposed to have a "mission statement" - a defining goal that describes what's its purpose. Why? To make sure that when you add some functionality later, you put it in the correct app, so you don't end up with 666 indistinguishable "small balls of mud".
-
You have a basic idea of how to test the application - it doesn't really matter whether you've got a full suite of automated tests or bunch of user stories for manual re-tests -> make sure that you have any of these, so you've got all what you need to make sure you don't cause regression problems.
-
Make sure there's an Owner - a person / bunch of people who care, want (& will) to take care about applications future. If ownership isn't clear, who'll guarantee one, coherent vision of application's future?
-
Even if this application is suited for the internal use, stick to the rules you have - Continous Integration, no manual operations, everything in source control, etc. - rules are like kata, the more you practice them, the better you get in using them. Use internal projects as an excercise battlefield: safe one, but still has to be treated with respect.
-
Make sure you "radiate" all the necessary information to the proper audience - if you don't several things may happen:
- people may just never hear about your application, so they'll re-invent the wheel by creating something equivalent. Wasted effort + reduced userbase + even more maintenance.
- the faster (& the more frequent) you get the feedback, the better - don't surprise your users by adding / changing something you haven't consulted with them: even if you believe you know what you're doing, you may suffer from "ivory tower syndrome"
Remember, even if you're creating something "unofficial", even if its a "skunkworks project", it doesn't mean you can afford ignoring all the rules that were set up & accepted to provide: the quality, transparency, stability & predictability. There's a big difference between "being agile" & "acting like a headless horseman".
Stay PRO.
