Better software through software architecture and devops


Monthly Archives: August 2004

  • They only seem to care because we, as software developers, make them play the requirements game. In reality, the only thing that matters is how the product matches up to their expectations. The big problem is that you can’t capture them in a document to use as the blueprint for development. There are some things you can to make sure your customer is happy with the result:

    1. Write a short “Vision” document describing the key features to get everyone on the same page early on
    2. Program by feature to produce functionality early, don’t spend too much time on infrastructure
    3. When you’ve completed a feature, show it to the customer and get feedback
    4. Allow the customer to change their minds

    These points will only work when both you and the customer share the project risk; either with fixed rates/variable time or fixed time/variable functionality.

    If it’s a fixed price/fixed functionality contract then you’d better start writing those requirements…

    This entry was posted in agile  and tagged #requirements  on .
    Discuss this on Twitter or LinkedIn
  • I have a meeting tomorrow to discuss a number of deployments we have in the next couple of weeks. One thing to note is that all installations come with their own set of problems and I don’t always have the answers. However, preparation is key; as they say - “pathetic preparation makes for a piss poor presentation”.

    One thing I’m going to try is a bit of brainstorming. I’m going to draw up each installation on a white-board and we’ll list up anything that could go wrong. From that we should be able to plan for nearly every eventuality. Hopefully it won’t be a too depressing experience.

    The main stay of my deployment plans is practice. If you have done it in the office without a customer breathing down your neck then the real thing is usually much easier. We try to get hold of a backup from the customer as they usually have data-sets containing unforeseen combinations of data (especially as the source database doesn’t have any constraints - shame on you Cisco!).

    The last thing that commonly trips us up is firewalls - most of our customers are in retail or banking so security is sometimes taken to the extreme. It would be costly for us to reproduce their firewall configuration (one customer has DMZ’s around each server), so a quick tip is to use personal firewalls such as ZoneAlarm to lock down your test servers similar to a DMZ deployment.

    This entry was posted in solution-architecture  and tagged #deployment  on .
    Discuss this on Twitter or LinkedIn