The SECRETS Of Successful Software Architects

Рет қаралды 10,995

Ай бұрын

Gregor Hohpe explains what it really means to be a software architect, how organisations can best succeed with their architecture and how to manage the complexities that arrive with both software engineering and software architecture practices.
This is a clip taken from Gregor's FULL first appearance on The Engineering Room, which you can listen to HERE ➡️ open.spotify.com/episode/4P4I...
-
🗣️ THE ENGINEERING ROOM PODCAST:
Apple - apple.co/43s2e0h
Spotify - spoti.fi/3VqZVIV
Amazon - amzn.to/43nkkRl
Audible - bit.ly/TERaudible
-
📙 Get my FREE Guide to Evolutionary Architecture here ➡️ www.subscribepage.com/evolve-...
-
🙏The Engineering Room series is SPONSORED BY EQUAL EXPERTS
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
-
#softwareengineer #softwarearchitecture

Пікірлер: 34

@rrmackay Ай бұрын

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.

@sarahannmadden Ай бұрын

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

@netdonkey2420 Ай бұрын

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

@brownhorsesoftware3605 Ай бұрын

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

@matkeyboard8054 10 күн бұрын

This channel is absolute gem, keep going 💪

@greggschofield142 Ай бұрын

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

@ajaaskelainen Ай бұрын

Awesome! Thank you 🙏

@ContinuousDelivery Ай бұрын

You're so welcome!

@denisblack9897 Ай бұрын

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

@csbc92 Ай бұрын

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.

@IronCandyNotes Ай бұрын

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

@siyabongampongwana990 Ай бұрын

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.