Engineering Personas meet Explore, Expand, Extract
I have always been intrigued with the idea of being able to identify one's engineering persona, and develop a framework (of thought) which would allow effective team building based on personal and professional traits.
Having spent a while in both academia and industry worlds of software engineering, I have been experiencing an increasingly disturbing feeling of disconnect between the two. In particular, between what is considered best practices in theory and what actually takes place in the industry. One particular aspect that has not been well incorporated into (empirical) software engineering research, is the human in the loop, or the social, cultural and human-centric aspects of software engineering as the authors of "Empirical Software Engineering: From Discipline to Interdiscipline" elegantly put it. We have little knowledge of how social and behavioural patterns in software engineering affect what came to be known as "best practices".
Take automatic refactoring for example, a brilliant technique to safely and quickly manipulate code in order to improve its structure. Is automatic refactoring a best practice? Has it been widely adopted by practitioners? Have the benefits of using automatic refactoring been empirically proven? These are all questions one would struggle finding conclusive answers to (even with the kind help of google scholar).
The more I practice and research software engineering, the more it becomes apparent to me, that there isn't one size fits all in software engineering. There are different practices, which offer different tradeoffs, that can be useful in different circumstances. Much like Alice in wonderland who asked the Cheshire Cat "Would you tell me, please, which way I ought to go from here?", to which the cat replied "That depends a good deal on where you want to get to". Is testing a good practice? Well, that may depend on how extensively the code under test is going to be used, on the cost of an error in that particular code, and a bunch of other factors. Turns out, this may not be a yes/no question after all.
Thinking Engineering Personas in the Context of 3X
Matching Personas to the 3X phases
The "Explore" phase
Goal:
- Obtain insights on what works and what doesn't
Tradeoff:
- Experimentation speed over maintainability & quality
Optimizes for:
- Iteration speed
Not really interested in:
- Well defined requirements
- Scale
- Code maintainability & quality
Explore Personas
- First Responders - likely to enjoy the fast pace, quick shipping iterations, lack of rigid processes, and the generally chaotic nature of engineering during this phase.
- Academics - likely to enjoy the exploratory nature of this phase, e.g., articulating experiments, making sense of results, coming up with follow up experiments, etc.
- Humanitarians - likely to enjoy the potential positive impact of success, on the community they identify with, e.g., if we succeed, we'll enable [audience] do [something] more [adverb], which would be absolutely awesome!
- Consultants - might get frustrated by the frequent change of requirements, vague/lack of business KPIs, and possibly little interactions with (internal) stakeholders due to initial team size.
- Craftspeople - might get frustrated by the fact poor code that gets shipped on regular basis, an environment where speed triumphs quality, and hacking is the norm rather than the exception.
The "Expand" phase
Goal:
- Support extensive growth
Tradeoff:
- Scalability over product features
Optimizes for:
- Making things stable
- Making things scalable
- Future growth
Not really interested in:
- (new) Product features
Expand Personas
- First Responders - the expand phase is likely to include two main efforts, (1) putting out fires caused by an influx of customers / product reach, (2) reworking infrastructure for growth. First responders are likely to enjoy the first, but might get frustrated by with the second.
- Academics - likely to enjoy ideating on creative solutions and novel approaches for scaling and addressing bottlenecks, be it infrastructure or product related issues.
- Craftspeople - likely to enjoy building non trivial infrastructure to address the scaling pains, scaling often involves mastery, craftspeople's wheelhouse. The combination of Academics generating ideas, and Craftspeople perfectly executing them seems to be an especially beneficial combination.
- Consultants - might get frustrated about focus shifting infra engineering, rather than business KPIs and product features.
- Humanitarians - might get frustrated with focus shifting from making impact via product features, to engineering efforts needed to support the rapid growth.
The "Extract" phase
Goal:
- Have a steady flow of product features
Tradeoff:
- Production stability over speed
Optimizes for:
- Safe shipping
- Production stability
- Maintainable and safe (e.g., tested) code
- Local optimisations for speed by means of hacking
Extract Personas
- Consultants - are likely to enjoy the maturity of the organisation in this stage, when there are many teams to interact with, and requirements are easier to define. Well defined business KPIs make it easier for consultants to get the satisfaction of moving the needle.
- Craftspeople - are likely to enjoy the focus on quality during this stage, where keeping production up is paramount. Elegant, tested and easy to change code is appreciated due to low appetite for risk characterising this stage.
- Humanitarians - are likely to enjoy the great product reach and therefore impact, that can be made through the features they ship.
- First Responders - unless put specifically on incident management, first responders may get frustrated with the extra attention to quality and process. Things can't just be shipped, they need to be tested, documented and reviewed. Code needs to have numerous non-functional properties for it to be deemed shippable.
- Academics - might struggle with finding big enough challenges to ideate about at this stage, where focus is likely to be on constant flow of (product) features, rather than revolutionising things.
Comments
Post a Comment