Better software through software architecture and devops

@jamessnape

Annual Archives: 2004

  • Sometimes, when you have to get a lot done in a ridiculously short time, you need a different approach. As a case in point, we need to replace all the remaining ASP code in our product with ASP.NET before we add some essential new functionality. If we don’t we will be stuck with the old code forever. This new functionality has to be delivered in a matter of weeks. It could be implemented in classic ASP but it will be much easier and faster using .NET.

    What is called for is a few days of pure implementation. No “discussion”, no “difference of opinion”, just code. It’s risky - probably only a 50% chance of success but if it works then we could save days in the immediate future and extra weeks down the line.

    There is a way this could work; by modelling the team on an operating theatre. In this setup, there is one person who does the bulk of the work backed by a second to give help and support. These two make the core pair - everything goes through them on the way into the product. The rest of the team are assigned packets of work by the core pair on an as needed basis. When the packets are complete they are given back to the core pair to stitch into the product. Effectively, one feature at a time is worked on by the entire team.

    The main benefit to this style of team is the minimal communication needed, resulting in a higher code to comms ratio. The packets of work are usually so small that they can be described in a couple of sentences. If the result is not quite right then the core pair make whatever changes are required saving the time usually spent explaining extra work to the developer.

    There are two key points to note before you embark on a development style such as this. Firstly, the core pair has to have a very strong shared vision of what the result should be. If not then you won’t be on a straight line to goal and too much rework will kill the efficiency of the method. Secondly, it can be a bit ego bruising to the non-core developers. They are told exactly what to produce, they have no real opportunity for free thought and the code they return may be modified or even not used. Nearly everyone can put their needs and feelings on hold for a week (even developers) but I wouldn’t push it beyond that. This is only for tiger-team style development.

    This entry was posted in agile  and tagged #surgical-teams  on .
    Discuss this on Twitter or LinkedIn
  • 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
  • I’ve just started reading “Agile Project Management” by Jim Highsmith and it’s looking very promising. Whilst reading chapter one the point slapped me like the Tango Man - it’s the way agile projects are different to others.

    Traditional project are all about deciding what you are going to build and then carrying out your plan whereas with agile projects you have a plan but it’s about how, not what, you build_._ In fact the key point made by Jim is that agile projects are all about experimentation and adaptions.

    He cites a comparison with the pharmaceutical industry which makes things very clear. A few years ago they used to sit down and design molecules for a specific task whereas now they synthesise thousands of molecules at a time and use automated testing to screen for desired properties. The results are fed into a database which the scientists use to make their next steps. This rapid experimentation enables them to generate new drugs much faster even though they don’t know  final until it presents itself.

    Consider this in the context of software development. Rapid cycles of experimentation with unit tests to screen the results and ensure forward motion. These two concepts enable a project to progress in a more efficient way than if a solution were “designed”.

    This entry was posted in agile  and tagged #book-review  on .
    Discuss this on Twitter or LinkedIn
  • Wallace McClure writes “What is the problem with Marketing People?” Where he makes the point that marketing people care more about selling product than learning about their customer’s business.

    I’m not sure this is especially a marketing affliction. In my experience they care more about “the message” that we, the vendor, wants to communicate. There is an old adage that “when you talk you are teaching whereas when you listen you are selling”. If so then their focus is probably correct. Leave the selling to the sales team.

    I do agree though that if you don’t take the time to understand your client’s business model you can end up damaging your relationship with them (and looking a bit stupid too).

    The thing to consider is the difference between commercial and business focus. The first is about sales, turnover and profit whereas the later is concerned with relationships, strategy and growth. Both are required but they need balance.

    Having had recent experience with customers wanting bespoke solutions for pocket change I’m not sure it’s always the best policy to try to get your product in by any means possible. One thought has just occurred to me - if you are a small company, is it better to lead with a product and provide professional services support or start with consultancy backed up by off the shelf product? Also, does it matter if you get the consultancy fee and don’t recommend your product because it’s not right for the situation?

    We used to have a very successful business model with the consultancy first option but have moved to a more product oriented focus. I’m not sure how it’s doing just yet. I’ll let you know.

    This entry was posted in business  and tagged #marketing  on .
    Discuss this on Twitter or LinkedIn