Data Science
Boundaries are essential in modern society: I simply can't take care of everything. But what are sensible boundaries in software development? Isn't every abstraction, a core of good software development, a boundary?
Especially when a project gets into trouble, everyone distances themselves and makes accusations: the development team did not deliver, the analysis was not precise enough, the project management lost the overview and the customer lost the measure. Setting boundaries can mean responsibility, but it can also mean retreating.
Compared to the Gotthard Base Tunnel, most projects are rather small. And yet Peter Jedelhauser, overall project manager for the Gotthard north-south axis at SBB, says when asked whether it was difficult to stand out [interview in Credit Suisse Bulletin, no. 2/2016, p. 19]:
"I try to avoid this word. Thinking in intersections is more efficient than thinking in separate units. If two people separate themselves, the chances of something falling between the table and the bench are extremely high."
Teams that clearly demarcate themselves create spaces in between. Issues fall between "chair and bench":
Teams with overlap appear as a compact unit:
This not only saves resources, but also coordination and therefore unproductive hours. Employees are also happier because they have more responsibility and influence over the entire project.
Only very small projects move in one shift. However, the team of analysts, developers and testers must understand all shifts and how they interact (Full Stack Developer(opens in new tab)). A great tool in a shift doesn't help if only a few people understand and need it.
The architecture must therefore match the team and its skills: With an average group, you can get to the valley faster on the blue or red piste than on the black one. With experts who have 10,000 hours of experience, you could master difficult terrain. However, these experts often focus on simplicity, because they know that someone with less experience will have to maintain the software later on.
Tiers not only bloat the Resolution, but also the teams. Which also requires a management shift for coordination. Therefore, fewer shifts, and teams that have end-to-end responsibility.
The impossibility of defining the requirements of complex development in advance has led to agile methods and prototyping. The distinction between analysis (with domain expertise) and development (with IT expertise) remains the crux of the matter. Either a requirement is converted layer by layer into a design that can be implemented by any developer (and thus delimited), or analysts and developers try to understand each other and work hand in hand ("Pair Analysis & Programming").
Understanding each other requires knowledge of development on the part of the analyst and knowledge of the domain on the part of the programmer. In my experience, this is a must - otherwise the effort immediately explodes.
A prerequisite for successful pair development is also a quick turnaround for results - that's why I favour interpretative and dynamic languages. A deployment mechanism that only shows results after many minutes (or even hours!) is not efficient and a disaster for a project.
Improving poor development through testing requires immense effort. If more than a few per cent of manual tests fail, the cause must be eliminated or at least the tests must be automated. This is the task of development, end-to-end in the integrated system. Testing and debugging with immediate feedback must be possible with real (or at least realistic) data. "Mock data" leads to illusions and should be avoided.
The professional testers should find exceptions and uncover gaps, not discharge the developers. A bug found by testing is a defeat for the developer!
The roles of chicken and pig (Chicken and Pigs(opens in new tab)) in the Scrum Process were nonsense, because they create a demarcation where there should be none, between customers and suppliers. In the worst case, this leads to small, well-defined playgrounds with many stories that are quickly and neatly processed and closed without the overall project making any significant progress. Naturally, the Pigs will set themselves apart and search for the Chicken to blame: Analysts, external suppliers, other architecture components, testers, etc.
It's hard to be agile. Contracts are static, so are management levels. It is important to let a Scrum process take place in the reality of the project rather than in a demarcated division. Scrum is a tool, not a substitute for leadership. The leadership must make it clear where agile planning is allowed, where the static general conditions are and how these are dealt with.
We now have NoSQL(opens in new tab) Data Bases that are dynamic and therefore no longer need to do schema design! Relational corporate integrity, goodbye!
Hold on! Data modelling remains the be-all and end-all of successful development, especially in an industry rich in data. We must not forget the lessons we learnt in object-oriented programming, such as abstraction, encapsulation and methods. NoSQL and JSON are additional tools at our disposal. Fewer re-runs (DRY(opens in new tab)) and transformations are their advantage. If this also makes the architecture simpler, all the better.
With clean data modelling, we achieve a better understanding between analysts and developers - and thus software that is error-free by design and not just by testing.
Barriers often provide comfort zones into which a sub-team can retreat.
Therefore:
This has proven its worth in one of our projects. What are your experiences? Do you have any counterexamples where a skilful demarcation has brought success?
Head Application and Business Services
Find the job or career world that suits you. In which you want to help shape and develop yourself.
What you make of it is what defines us.
