Balancing Best Practices with Rapid Development

Balancing Best Practices with Rapid Development

“A good plan today is better than a perfect plan tomorrow.” -George S. Patton

Rushing a project is the easiest trap to fall into as a developer. Working fast is a must in today’s marketplace, however foregoing a plan and ignoring best practices will ultimately slow down a project and create more work later.

So how does one balance best practices with rapid development? I think the answer is in the question: Balance.

Here are some tips for building sustainable, scalable projects while keeping development quick and nimble.

Plan & Create Specs

“By failing to prepare, you are preparing to fail. ”
– Benjamin Franklin

A plan may be as simple as a drawing on a whiteboard or as involved as a full-blown document with wireframes, flowcharts, ERDs and business objectives. Without a plan a project will meander and lack focus.

Utilize the planning process for discovering potential issues, encouraging discussion, brainstorming and determining what is important to the business objectives. Prevent feature creep and future changes by getting sign-off from client and/or decision-makers.

Don’t Cut Corners on Front-end Design

Take the time to create an intuitive design with a smart workflow. If the UX makes sense then less documenting and training are needed and coding objectives are clearer.

Build It in Phases

If all of the project doesn’t need to be done at once, then don’t do it all.  It’s better to have one thing that works great than 10 things that work so-so.   Just make sure the project is designed with future phases in mind so adding new functionality isn’t a burden later.  Plus, smaller and more frequent releases tend to reduce bugs and is easier to manage.

Test, Test, and Test

Not familiar with test driven development (TDD)? Watch this video.  Building tests that fail then writing code to make the tests pass may feel counter-intuitive at first, but unit tests are a best friend, especially if sleeping at night is a goal.  Back-tracking and fixing code that stopped working is time consuming. Unit tests keep things working by continuously testing previous code as new code is added.

Unit tests are great, but they cannot replace human testing.  Ask or hire fresh eyes to test pre-releases in a test environment prior to deploying to production.   It’s easier, more cost effective and less stressful to catch and fix bugs when they are NOT in production.

Document As You Go

Documenting is a small investment now for a big payoff later.  Even the biggest brains can’t remember every little intricacy of a well-developed project — It’s a real time-saver to have a reference.  And assimilation of new developers and/or contractors is simplified as a team/project grows.

Ways to document include: Online tools like JIRA, a WIKI, or Basecamp;  Revision control  (SVN, CVS, Git, et al.) that should always be used and commented explicitly;  Release notes to document bug fixes and added features; And, at very least, comment the code.

Don’t Repeat Yourself — I Said Keep it DRY

I’m not a big fan of over-abstracting; I like to keep code simple and straight forward. But if there is any replication, find a way to abstract it!

Frameworks and plug-ins save a ton of time by getting grunt work out of the way (and in most cases better than I could do it) as long as the level of customization in the project allows.  No need to reinvent the wheel.

Security

Be as secure as the project requires – an online bank requires more security than a hot dog topping database.  Taking higher security risks can speed development, but don’t cut corners.  Dealing with hackers and security issues are costly and time consuming.

Separate Dev and Production Environments

Create a safe place (playground) to develop code and freely experiment without fear of breaking things.  Local computer, virtual server, cloud, or an extra server that mirrors production as close as possible can be suitable development environments.

Work Smart

  • Prioritize tasks – follow the money and listen to the client
  • Task jobs to appropriate talent
  • Hire smart people (I always try to hire people smarter than me with skills I lack)
  • Build, Partner or Buy? I don’t know the right answer, but it’s worth asking
  • Focus – create an environment conducive to your work style
  • Transparent communication with team, client,  and decision makers is the ONLY way to navigate issues
  • Stick with what you know
    • The latest isn’t always the greatest
    • Don’t experiment with new technology when speed is a goal
    • Choose best platform (Usually what you know best, but not always — consider the big picture and who will be ultimately managing application.)

Backup (Need I Say More?)

Hardware is fickle.  There’s nothing worse than losing data or code from something totally out of your control.  So BACKUP!

Data recovery is extremely time consuming.  Make and keep frequent backups of databases.  Revision control has some inherent backup of code built-in.  And If redundancy is in the budget then load-balance servers.

Managing Releases

Finally, if managing the project long term, be sure to monitor the application.  Keep an eye on logs and take the time to set up automatic notifications.  Find errors and fix them before the client and/or manager is even aware.

Conclusion

I’ve learned (and am still learning) lessons the hard way.  Hopefully these tips can help you sidestep some of the heartache and sleepless nights I’ve encountered.   But remember: It’s OK to make mistakes.  Sometimes it’s better to make mistakes and get something working within a given time frame than to do everything perfectly and it never gets released.     Happy coding!