Giovanni Asproni

Giovanni Asproni

Director at Asprotunity Ltd, UK

Giovanni has worked in many roles in several application domains. Nowadays, he provides consulting, training, and advice, as well as coding, to projects of all sizes: from small ones carried out by co-located teams up to projects involving hundreds of developers split into geographically distributed teams.

He is a past Chair of the London XPDay and the ACCU conferences, and the Industry & Practice co-chair for XP2016. He is a member of the Agile Alliance, the ACM, the IEEE Computer Society, and a contributor to the “97 Things Every Programmer Should Know” book published by O’Reilly.

Speaker's activity

Creating An Incremental Architecture For Your System: What, Why and How

November 12th




Experience taught us that creating an architecture for a system with a big design upfront is a bad idea as, usually, we don’t have all the necessary information to design the system at the very start—even in moderate sized systems requirements tend to change significantly, often making the initial design unfit for purpose.

On the other hand, no upfront design can be just as bad—the code tends to become unmaintainable pretty quickly, and system qualities like performances, scalability, security, latency, etc., can be very difficult, if not impossible, to retrofit.

In this talk I’ll show a different way to create a software architecture with just the right amount of design that can be incrementally evolved (or changed) as the system grows and changes—by taking care of some important qualities of the system early in the design, and delaying the design of other aspects to the last responsible moment.

Design for Testability: What, Why and How

November 11th




“To be tested a system has to be designed to be tested”
Eberhardt Rechtin, “The Art Of System Architecting”

Testing is one of the main activities through which we gather data to assess the quality of our software; this makes testability an important attribute of software – not only for development, but also for maintenance and bug fixing. Design for testability is a term that has its origin in hardware design, where the concept was introduced in order to make it easier testing circuits while reducing the costs of doing so.

In this talk I’ll show how to translate this concept to the software domain along with the consequences on various aspects of the development activities, both from the technical point of view (e.g., design, code quality, choice of frameworks, etc.), and the product management point of view (e.g., management of team dependencies, delivery time, costs, etc.).

I’ll provide examples based on real world experience, both for the technical and the management aspects. Last but not least, there will be code!