As recently as 2 days ago I was explaining to a senior engineer to stop chasing the edges cases. My viewpoint is implement the 80%/90% use case, test it, deliver it. Then when a customer asks about one of the edge cases then prioritize and build it. Spending time analyzing every use case up front is not agile.

@psychic8872

Ай бұрын

I think the point of the video is to pick a tradeoff between complexity and flexibility. If you know the 10% use case will come and the complexity to account for it in the design (not necessarily implement it) is low, you should go for it.

@queenstownswords

Ай бұрын

Per experience, chasing that 10% can often drop the ROI. If the client asking for the edge case pays a lot, you might say 'yes'. If the client asking for the edge case does not pay much, you may need to say 'no'. A trap many shops fall into is not having the 'strength' to say 'no'.

@Divus90

Ай бұрын

That trivializes a little bit the complexity of creating software. I've been part of rewriting the system from scratch, because the use cases that were previously within those 10% has started to be a really big deal (and basically a sales point), and architecture of the old system made it impossible to solve this in a good way. It's also different if you implement 80% of the things that you know are the requirements and don't expect anything new to appear, or you implement 100% of known requirements and just know the there are more unknowns icoming. I tend to spend a lot of time asking users / business what would be the next step for functionality, or interpolate it with a team. This way I can actually make system that can accommodate those changes with quality in mind.

@evgenylahav

Ай бұрын

It's also a matter of severity. Uncovered edge cases will result in SW failure. If the worst case of this SW failure is an uncompleted commodity deal, then you're totally right - no need to over engineer. But if such a failure can lead to plain crash or malfunction in car brakes, then you better handle these edge cases because the severity of the errors is too high.

@rrmackay

Ай бұрын

@@evgenylahav I didn't say I ignore edge cases rather that I don't do that analysis up front. Each case is researched and designed in its own iteration. Implementing the main use case for a feature may invalidate the research done on a participial edge case. That is the entire problem with waterfall, while you can do upfront design it may be wasted effort by the time you are complete.

Mind blown, the trade off of flexibility is complexity, so true and yet I’ve never heard it summed up like that anywhere

I like this format of short excerpts from the long interviews. The interviews are great, but long (a feature, not a bug 😉) and sometimes it is perfect to bring back the best moments.

@riccardo-964

Ай бұрын

pro-tip: install a video accellerator and watch videos at 1.5x, you will reduce 10min interviews by half.

@RicciardoJohnson

Ай бұрын

@@riccardo-964surely this would reduce a video of any length by 1/3rd?

@riccardo-964

Ай бұрын

@@RicciardoJohnson by any rate you can handle actually - my limit is 1.8x - more I can't understand

Something I noticed already very early in my career when I worked on a mainframe ATM system was a reluctance to interact with folks in other parts of the business. This astonished me. Rather than consult with the people in their banks, they wanted to ask other data processing centers how things should be implemented. And the answers they got back were insane. So I ignored them and bonded with the people in the banks instead. The gm backed me up and the implementation was a roaring success: first banks to go live by weeks. Since then I have seen this pattern repeated ad infinitum. Perhaps software would be better off if engineers paired with users instead of other engineers.

@MK-lh3xd

Ай бұрын

If you are an in-house software engineer, this approach works. But if you are a software engineer from a vendor company not colocated at the client site, it is very hard to get the time of the client business folks since they have a day job to.do. Also if you have a contractual deadline and fixed cost, it makes the times waiting for business folks very expensive. You were lucky you had the backing of a GM.

@brownhorsesoftware3605

Ай бұрын

@@MK-lh3xd Actually, after implementing a second next generation of the ATM system, I had five years of a successful PC software business doing the projects that in-house departments turned away. I developed an excellent phone manner and found physical proximity not to be an issue. It all went well until the economy tanked and project funding dried up. In those 5 years I did 30 projects with only one failure (my single attempt at RPG III).

@brownhorsesoftware3605

Ай бұрын

@@MK-lh3xd Another astonishing thing about sw engineers is how quick they are to say another engineer's success is because of luck and special circumstances. In reality that is rarely the case.

@MK-lh3xd

Ай бұрын

@@brownhorsesoftware3605 alright man. May your succeses continue. Good luck. Sorry, I shouldn't say that. You go dude🙏👍

@olge1355

Ай бұрын

@@brownhorsesoftware3605 exactly, everyone is always the "special case" :D

This channel is absolute gem, keep going 💪

Absolutely loving the Gregor Hohpe! Platform Strategy is in the post!

Awesome! Thank you 🙏

@ContinuousDelivery

Ай бұрын

You're so welcome!

The secret is simple: build stuff that works, refactor and abstract right before you have to pass the code to the maintainers. If you refactor and abstract in the process you won’t make progress, just overengineering for the overengineering sake

Design the software for anticipated changes (flexibility). Sure, you can anticipate anything (complexity). The difficult part is be good at anticipating the variability points (aka hotspots). This comes with experience and a lot of failures. Make a few architectural prototypes and play with it - see what works and what doesn't. Refine and repeat.

Everyday management spends some braincells on architecture is a great day.

Do you think a software architect would benefit from practising "reverse mathematics" ? Or at least knowing the fundamentals of Rev-Math? My theory, is that it would, but I'm not a practising Soft..Architect so I don't quiet know how Rev-Math would actually fit in real life...I'm just theorizing. Anyway Does anyone think that Reverse Mathematics can be used in Software-Architecture?

@rrmackay

Ай бұрын

I think you may find Architecture Patterns to be of interest, they represent axioms of designs as opposed to axioms of processes. I have formal pattern identification steps in my process that allows me to speed some design steps. I would classify the requirements as the theorems and the patterns as axioms generally derived from the requirements. This means similar to mathematics that you have to digest the requirements before you can make any architecture decisions. I hope that helps. Search for martinfowler enterprise patterns

@Mig440

Ай бұрын

If by reverse mathematics we understand the approach of going from theorems/results back to axioms/rules then sure in that generality yes. I dont think using reverse mathematics in itself is helpful to software architects since most software systems are not feasibly analyzable as a formal system which mathematics tends to be. I say that as a mathematician turned software architect 😊

@siyabongampongwana990

Ай бұрын

@@Mig440 cool, and thank you for the quick reply.

"Excessive complexity is the punishment for organisations unable to make decisions" hehe