In anticipation of Gernot Starke's and Peter Hruschka's workshop, Two Shockingly Recurring Problems, Richard Wallintin (WPS - Workplace Solutions) had a number of questions for them about the nature of these recurring problems, and their efforts to overcome them with systematic methods.
Your workshop’s premise is that some basic struggles in software development appear to never go away. You address improving requirements and improving grown systems, but do you believe there are more “shockingly recurring” problems?
You are right – there are definitely more than two recurring problems – but in our opinion, having mediocre or bad requirements is by far the oldest, most widespread and most unneccessary of all.
By unneccessary we mean that it’s fairly simple to resolve: getting better in requirements does not require expensive tools or lots of effort, but a purely methodical approach by the team.
Improving existing systems needs more effort, but with a systematic approach it surely is manageable.
Close follow-ups in the „most dreaded problems in sw-development“ are low-code quality, missing automation (aka too many manual tasks in testing and delivery), bad documentation, and missing explicit architecture and architectural decisions. We discussed the „too-bad-coffee“ issue, but the latter has gotten better in recent years, at least in our subjective evaluation.
Your names are associated with a few methods (or frameworks) that appear to be a family, at least they all have the last name “42”. The most prominent is certainly arc42, which at times seems to already be a de-facto standard in German-speaking countries. Do you see that as the goal of arc42, and is it accomplished? What about aim42, req42 – are you ambitious about widespread adoption of these methods?
Nearly 20 years ago, when we discussed the need for a more systematic approach to software architecture communication and documentation, we were looking for an appropriate name for our „idea“ – and stumbled upon the „42 as the answer to everything“. It might be a bit over-ambitious to have an answer for everything, but arc42 aims to give at least some answers to some of the urgent and important questions regarding the architecture of specific software systems.
It was not our goal to set a standard, but we are proud of the wide adoption in industry, meanwhile not only in the german-speaking countries, but also in many other European and Asian countries. Our goal mainly was to avoid useless discussion about documentation structure and to allow teams to concentrate on building good systems. Lots of teams seem to enjoy that.
Later, when helping to rescue and maintain existing legacy systems, the 42 came in handy again: This time aim42 was the answer to the urgent and important questions regarding legacy renovation, evolution, maintanance, and optimization.
req42 is the latest in our list – helping to improve requirements. It is a simplifcation of the well-known VOLERE-framework, adapted to the agile world.
A common theme in all our approaches is that everything is open-source, and feedback from the community is welcome.
Both of you have a lot of work experience to look back on (meaning seniority, not age.) When thinking about the valuation of factors and skills that used to be called “soft”, do you see change in the software world? And is it progress, i.e., change for the better?
Soft skills like interpersonal communication have received increased attention and understanding together with the growth of the agile movement, therefore, things have gotten better over time. But we’re still far away from great or perfect - as too many software development projects fail or at least suffer due to human issues (aka layer-8-problems).
And as a follow-up: If you were entering the space of software development today, what aspects of the work would you tackle differently? Would you have other priorities?
We still consider our methodical approaches (instead of other, more technical or product-oriented) a great success factor in the long run.
Looking back, we would not change much, but emphasize pragmatism instead of doctrines, simplicity instead of formalism, and good practices instead of theory even more.
You are associated with systematic approaches to architecture development, improvement, and requirements engineering – rather formal, some would say. In the bubble of agile software development, the need for formal requirements engineering is disputed and extensive documentation is quickly put off as waste. Do you feel there is a conflict as to what is the “right” amount of formal/written and specialized disciplines? Or is it all about context?
People who know us better will surely refrain from using the term „formal“ in conjunction with both our names, as we both have a very pragmatic approach to development.
Consider your household: Being pragmatic in housework does not mean letting your living room slowly develop into a junkyard – but it’s about the appropriate mixture of discipline and freedom.
For us, the final result (working software) plus the appropriate methodical preparation for the future (e.g., upcoming releases) are the main goal. If a collection of rough pencil sketches suffices for a certain team and situation, it’s perfectly okay for us. Neither arc42 nor req42 prescribes „large, extensive“ documentation.
By the way, there is proof in this thesis: 30 of the currently 144 online tips regarding arc42 (see https://docs.arc42.org) refer to lean, pragmatic documentation.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
