Over the past two projects, every time I’ve realized I made a mistake, I’ve made a note to myself. (”Lessons Learned”, in business jargon.) Here’s a collection. (Yes, some of these are “well, duh” statements - they’re here to document situations that I let business inertia drag me into.)
-Check project management resources for frequently missed items in estimating project timeline.
-Be sure to to document user classes and areas of interface they must be allowed to access/denied access to.
-Release Management/Operations needs to know when daemons actually terminate if they don’t die right away.
-Set up one of every type of network connection on localhost for dev (and other environments), so you can test functionality that uses these protocols.
-Structure modules/methods in such a way that they can be easily unit tested!
-Support all options for a protocol in your config files, not just those you initially plan to use.
-Document default values for all configuration options, reasons behind them.
-Ensure systems administration and database administration are on signoff list for technical design, so they can raise security/efficiency issues.
-Never use any unencrypted protocol, even within an intranet; other departments are likely to block it.
-Estimate time up front to build unit/integration test harnesses, builder/installer for all environments.
-Project managers always assume developers will be allocated 100%, when in fact it is more like 80%.
-Note all servers for project and types of connections made by application, then request setup from Systems Administration prior to beginning coding!
-Plan around reloading config before accessing each option, so changes can be made without shutting down.
-Use one config hierarchy for everything, so you don’t have to manage multiple files.
-Allocate time for TDD revisions, as other departments review it for the first time.
-Calculate expected load on networks, databases, etc. in advance.
-Ensure vendors fully understand all requirements (and their difficulty) before signing any work agreements.
-Don’t accept specifications that are vague or open to interpretation, as requester is likely to reject finished product.
-Write down all figures you give to others in meetings for later reference (such as effort estimates).
-Skimping on code reviews costs almost as much time as it saves, and may result in a lower-quality product.
-Monitoring tools must raise alarm if items in processing queue get too old.
-Manual installation of files not advisable. Consider making RPM.
-Specify precise file locations and names for each module in technical design.
-Maintain separate config directories for development, testing, production!
-Ensure all generic accounts (FTP, database, etc.) are created well before rollout!
-Specify whether paths will be absolute or relative.
-Use ’set’ as a verb in method names rather than ‘add’, unless you intend it to fail if the value already exists.
-Perl is a poor language for outsourcing.
-Perl is a poor language for building large applications.
