Data Mesh Principles and Logical Architecture The great divide of data What do we really mean by data? The answer depends on whom you ask. Today’s landscape is divided into operational data and analytical data . Operational data sits in databases behind business capabilities served with microservices, has a transactional nature, keeps the current state and serves the needs of the applications running the business. Analytical data is a temporal and aggregated view of the facts of the business over time, often modeled to provide retrospective or future-perspective insights; it trains the ML models or feeds the analytical reports. The current state of technology, architecture and organization design is reflective of the divergence of these two data planes - two levels of existence, integrated yet separate. This divergence has led to a fragile architecture. Continuously failing ETL (Extract, Transform, Load) jobs and ever growing complexity of labyrinth of data pipel...
Pair Programming Misconceptions
A bunch of common misconceptions about Pair Programming.
You have to do pair programming if you're doing an agile process.
This is utterly false. 'Agile' is a very broad term defined only in terms of values and principles, most notably in the Manifesto for Agile Software Development. The manifesto doesn't mention pair programming and most agile methods don't make it part of their approach.
Since pair programming is a practice of XP it's had a lot of influence in the agile community. As a result it's often mentioned as an agile practice - meaning a practice that's commonly used by people on agile projects. But that's an observation not a prescription.
Extreme Programming forces you to do Pair-Programming
This is much more nuanced issue. Pair-Programming is one of the practices of XP and has been since its inception. The nuance here is whether XP practices are mandatory for a team that claims to be doing XP. This is actually a much more tricky question than it may seem at first sight. XP, like any agile method, expects a team to choose its own process. In Extreme Programming Explained Kent says that practices are "the kind of things you'll see XP teams doing day -to-day". I would say that pair-programming is usual for XP teams. I wouldn't say that a team that doesn't do pair-programming thus cannot call itself an XP team. I should also point out that to most XPers I know the question of whether a team is XP or not is uninteresting; the real issue is whether a team is effective.
The closest I'd get to forcing pair programming would be to say that if you want to learn how to do XP you should try pair-programming and see if it works for you.
I don't need to try pairing because I know I won't like it.
The problem with this statement is that many people have been surprised by pair programming. They gave it a try, expecting to hate it, and found they really liked it.
This is further complicated by many people trying out pairing badly - which can give a false impression. Hours passively staring over someone's shoulder in a corner cube isn't pair programming. Make sure you have someone who really knows how coach you, so you can be sure you're evaluating the real thing.
Pair-Programming halves the productivity of developers.
My flippant answer to this one is: "that would be true if the hardest part of programming was typing".
Advocates of pair-programming are advocates because they believe that a pair is actually more productive that two separate developers. This is due to the continuous discussion and review that pairing introduces. You come up with better designs, make less mistakes, and make more people familiar with the code. All of these things offset having less people typing.
Of course, since we CannotMeasureProductivity we can't know for sure. My view is that you should try it and the team should reflect on whether they feel they are more effective with pairing that without. As with any new practice make sure you allow enough time so you have a good chance of crossing the ImprovementRavine.
It's only worth pairing on complex code, rote code yields no advantage.
I think there is a point to this - pairing is about improving design and minimizing mistakes. Rote code that's simple to write yields little opportunities for pairing to make a difference.
Except this: writing boring rote code is a smell. If I'm writing boring repetitive code it's usually a sign that I've missed an important abstraction, one that will drastically reduce the amount of rote code to write. Pairing will help you find that abstraction.
Yorumlar
Yorum Gönder