What do you wish developers would do differently? [closed]
As a developer, I spend most of my time thinking about the code, UI, data structures and so on, but (I bravely admit) I don't tend to consider the implications of my app for sysadmins and DBAs until it's time to deploy the app.
Firstly, I'm sorry. Secondly, what do you wish I, and other developers you deal with, would do differently? What things would make life easier for you, cause fewer problems, encourage co-operation, and reduce crashes, performance issues and configuration nightmares?
- Think about and build in security from day 0.
- Use version control for everything: source code, documentation, configuration, etc.
- Documentation, documentation, documentation.
- Clean installation and de-installation, using platform-native packaging
- Separate configuration data from libraries and executables
- Support for running different versions in parallel for testing and migration
- Robust, configurable logging
- Lightweight, accurate, secure monitoring
- Application checkpointing and backup
- How does your application react to problems: out of memory, file system full, network down, missing/corrupted configuration files, time skew?
- Always have separate development, testing and production environments. With all the free VM sofware, there's no excuse!
Remember that your application probably has more states than up or down. Draw a state diagram. Most applications have states like:
- down
- initializing
- recovery
- up-but-not-accepting-work
- waiting
- checkpointing
- processing
- finishing up
- shutting down
- down
Think about what happens if the system crashes during each state. How will a sysadmin monitor and control state transitions?
Distinguish the "user" from the SA.
A "user" needs to know how to use your software. Users don't care about things like how to install your software.
The SA doesn't care how to use your software, but needs to know some critical details about how to install the software.
Write documentation separately for each of those roles, including the information relevant for each of them.
One of my wishes is inclusion of proper messages in exceptions and error codes. It's completely opaque to someone who has not developed the application what a JimmyNotAtHomeException: it's late! means.
But a message such as Unable to find jimmy - initial manual call_mother procedure is very helpful.
Communication, communication, communication. Every problem between a sysadmin and a dev can pretty much always be tracked back to a lack of communication. If prior to a project the sysadmins (or a representative thereof) and the devs got together and had a nice framework discussion, SOOOOOOOOOO many problems could be avoided down the line. I can't tell you how many things get fouled up because you develop everyone on one box in development only to watch it go down in flames in prod because the app then gets separated in to App server + DB server + interface server, etc. Kudos for bringing this topic up.
Engage us early in the project. Like real real early, at functional spec stage.
Somebody else mentioned having to manually install on every PC, but the same applies for config and config changes. If you choose to store something like connect strings client-side, and need to update them on a regular basis, we will probably want to kill you.
Choose technology that can be properly centrally managed and configured, for the very same reason. Make sure that it integrates well with whatever central management tools we use.
Always test using the lowest common denominator. That means as a non-Admin, on the most primitive OS, applicaion suite and browser plaform in common use. We don't like having a required browser upgrade for all of our users landed on us at the last possible minute.
Don't jump to blame us when things go wrong. In my old job every time an app broke the developers would instantly point the finger at us. "You installed a new patch, you won't upgrade browsers, your security is too tight" or whatever. This generates a destructive atmosphere. We're on the same side, really, and we want to work with you to fix it, but we can't in those kind of circumstances.