Tag Archives: management

Treat Performance as a First Class Citizen

Steve Souders wrote a very interesting blog post recently (http://www.stevesouders.com/blog/2013/08/27/web-performance-for-the-future/) about treating “performance as a discipline”.

The premise of this article was that performance is such a fundamental issue that a separate team should be created to focus purely on performance.

Seeing this view put in writing by one of the leaders in the performance arena was very refreshing to me. At Intechnica we have been pushing this message for a number of years and it is nice to finally see it gaining some traction within the industry. We formed the company to deliver this capability into other companies.

For me the battle that we face day to day is the battle to get people to treat performance as a First Class Citizen within the development industry. There does often still seem to be a sense that good performance is just something that developers should be able to achieve with more time or more kit.

The reality of course is that that is true up to a point. If you are developing an average complexity website with moderate usage and moderate data levels then you should be able to develop something that performs to an acceptable level. As soon as these factors start to ramp up then performance will suffer and will require expertise to solve the problems. This does not reflect on the competency of the developer, it is just a reflection that a specialised skill is required.

The analogy I would make to this would be to look at the security of a website. For a standard brochureware or low usage site then a competent developer should be able to deliver a site with sufficient security in place. However when the site ramps up to a banking site you would no longer expect the developer to implement the security, there would be an expectation that security specialists would be involved and would be looking beyond the code to the system as a whole. This is no negative reflection on the developer, just that the nature of security is so important to the system and so complex that only a specialist can fully understand the solution that is required. This is acceptable because security is regarded as a First Class Citizen in the development world.

Performance issues often require such a breadth of knowledge beyond simply looking at the code (APM tooling, load generation tools, network setup, system interaction, concurrency effects, threading, database optimisation etc.) that specialists are required to be able to solve them.

These are not better than developers, they just have different skills.

At Intechnica we have run projects where we have a performance scrum team. Leaving developers to deliver functionality with usual performance best practice but no specific defined KPIs. Then applying the acceptance KPIs afterwards and passing failures onto the the performance scrum team backlog.

We have also developed projects with performance engineers within each scrum team and applied KPIs as part of the feature we were developing and to the system as a whole.

Both are valid approaches. There are other valid approaches. As long as performance is treated as a First Class Citizen then you will be on the right track to performance success.


Leave a comment

Filed under Opinions

6 Rules for Good Specifications in Software Development

In recent months we have overhauled the Intechnica development process to use a lot of the BDD – Behaviour Driven Development –  and “Specification by Example” (http://gojko.net/) processes and tools for specification definition. As such we have defined the 6 rules of good specifications:

1. Communication between client, BA, QA and developer:
The more all of these people talk, and the earlier they are involved in specification stage, the better.

2. Don’t define user experience and business functionality in one place.
It leads to repetition and confusion. It also tends to lead to underlying systems designed around the UI rather than the business domain.

3. Illustrate all business logic with examples
…not with wordy descriptions.

4. Illustrate all UI with annotated pictures
…or ideally full HTML prototypes.

5. Specifications must be testable to form objective acceptance tests.
Tests should be automated and built into your continuous integration process.

6. Specifications should be living documents
…and evolve into the living documentation of the system.

View some of Andy’s presentations about software development on Intechnica’s SlideShare


Filed under Opinions