Starting a new project?

OK, so in the current economic climate, you may not be embarking upon dazzling new projects. But you never know, and some tips are always useful for maintenance work, so herewith some pointers for the developers out there looking to start big(ish) pieces of work. We’re kind of assuming web development here, but hey, some things apply no matter what…

  1. Decide your approach Are you coding from scratch, making use of a framework, what? This is closely coupled with point #3!
  2. Source control from the start Please. You. Must. Have. Some. Version. Control. Going. On. Even if this just means someone taking a build of your app / site each night and squirrelling it away on a thumb drive—something!
  3. Agree some standards Where are you going to put your scripts? Or how will you name your classes? Logging and error handling? If you’re doing the Domino thing, make sure you have standard error pages which everyone writes their messages to. Make sure all are agreed as to whether you’re using profile documents, normal documents (or a mix) for application configuration
  4. Get your environments in order At an absolute minimum you need development, test and live. As a minimum. And these environments need to be mirrored as much as possible. I’ve developed on Windows / Tomcat to deploy to Solaris / Websphere, and it’s not fun (even if you drop Websfear).
  5. Documentation It’s a lot easier to document idiosyncrasies and core components of code as you go along. Trying to figure out why the hell you did something three months after the fact is time-wasting, frustrating, and foolish. Again, use your Version Control: make atomic check-outs, and comment them!
  6. Build and release often Don’t go for the “big bang” approach. So many project risks can be mitigated by putting something on the target environment early, even if two thirds of the thing is broken or missing. These issues might not even be technical—the same applies for questions around user acceptance. You’d rather you found they hate everything about your form design when you’ve coded up one, rather than sixteen of the blighters eh?
  7. Code for testing We’ve all done it, just knocked out some code using a familiar pattern, and deployed it. But if your code is doing anything significant, consider investing time and effort in (a) making it test-able and (b) actually testing it. Apart from anything else, things like JUnit integration in your IDE of choice mean lots of fuzzy feelings as your progress bar goes green rather than red.
  8. Never ascribe to malice (or Domino administrators) that which can adequately be explained by stupidity
  9. Out of office notes Another reason to keep that documentation going: don’t leave your fellow developers in the lurch. If you code something amazingly complex, release it to test and then bugger off on holiday for two weeks with nary a word, no-one will like you
  10. Celebrate success When you deliver on something, celebrate the fact: go out for lunch, for beers, whatever floats your boat, but do something to mark the occasion. Relentless work minus proper milestones does not a happy team make
  11. Talk Even if you’re not working in a team, endeavour to discuss stuff with fellow developers. Describing a programming issue engages a different part of your brain to that used when simply thinking about something. All seasoned developers have tales of abruptly stopping halfway through an explanation of a thorny code problem, because they’ve suddenly hit upon the resolution.
  12. Don’t go dark Plenty of others have discussed this phenomenon, and it’s crucial. If members of the team aren’t communicating issues and resolving things, there will be trouble!

Apologies if some of this comes across as notes for elderly matriarchs on imbibing ova, but I think the obvious often bears repeating.


  1. "websfear"… like it!!!, mark#
  2. @7 - FYI, I posted a tool for unit testing in LotusScript on openntf - Domino Unit Framwork. Which gives you ticks and crosses for passed and failed tests. It's not as nice as jUnit - but does mean you can unit test LS code. It's open source which means you can extend it to include your own custom classes. It's sort of basic but I found it useful, maybe someone else might.

    some great advice on good practice.Tony Palmer#
  3. Oooh thanks Tony, will take a look! I played with LSUnit a few years back, so would be interested to look at your project. Here’s the link for everyone else:

    Ben Poole#
  4. Its amazing how many Notes devs don't subscribe to many of the points above because they consider them anti-RAD.Grant Norman#

Comments on this post are now closed.


I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.