SE-Radio Episode 287: Success Skills for Architects with Neil Ford

WARNING: Unstructured extract from http://www.se-radio.net/2017/04/se-radio-episode-287-success-skills-for-architects-with-neil-ford/

People makes architecture decision even if it not in their title or qualification.

For an architect “soft skills” are essential like presentation skills. Nowadays there are higher standards against architects. Nowadays architect should think of DevOps aspect of the architecture. Architect responsibility is broader than before. Much more thing to consider.

Architects needs to stand meeting. So if you do not be able to stand a meeting then you are fucked up.

There is leadership aspect of software architect.

A really effective one should be good speaker and presenter. Be able to speak not only for technical but to business people.

Most important characteristic of software architect:

How to handle not to be as technical as before?:
Keep developing. But not on the critical path. One of the best way to pair with a developer.

How to transfer essential knowledge to developers

Q: Keeping Simple is hard - what do you think?:
Why is it going so complicated over time? The why things got more complicated because metawork is more interesting then work.

e.g.: Writing a new framework is always more interesting than using an existing one to create something valuable to the company. At the end your job is simply read, put value and write back to database. Metawork is much more brain challenging. (E.g. replacing Angular to React because they “assume” it will be better in the future)

Q: Learn from history. Why is it interesting?:
Learn how to make decision about things (Dreaming in Code book) Infinite resources (aka no constraint) could still drive to project failure. Is there any value in the thing we are doing?
“Are we delivering value?”

Q: help young engineer the importance to learn from history:
Not to run into the same problem over and over again.

Component replacement: we think it is like replacing LEGO. But it is more like organ transplantation.

Q: Clever Code:
Useful sometimes but in general it is not good. Good examples: multi-paradigm languages. That is the why multi-paradigm languages cause trouble (e.g. Scala). Too many way to do the same things. So it could be difficult to others to understand. Anytime the tool has SIMPLE in it name that it is probably not simple at all, marketing only (e.g.: sbt, SOAP). Don’t create too clever stuffs. Developers like creating clever stuffs.

Eliminate complexity!
Be aware of accidental and essential complexity. Example: Routing physical mails. Accidental complexity is when the routing is done by complex character recognition algorithm instead of (e.g.) color code/unit of the paper they use (blue color for unit1, red color for unit2, etc.) what is much simpler.

Bring changes to organization. How?:
“Demonstration defeats discussion”. Stop talking about stuff. Show them how it will be working. Even if a simple version. It will beat complains It helps bypass procrastination. Show them it is useful. Demonstrate and they will see how simple it is. Find a “pain-point”. What is really a problem to them? Solve the problem and demonstrate how it is possible in the “new ecosystem”.

Operations are essential part of software systems. They are part of the feedback loop. (If an operating system upgrade breaks the code it is not the operations who is fixing but developers, so they must cooperate) They must be considered. Even such a things like operating system upgrades. Operation issues are fixed by devs at the end. Move the code to production like system as soon as possible.

Keep the Technical Debt low.

Don’t put road blocks in front of developers. Encourage people to do what they have to do. E.g. We expect to refactor by enforcing to use feature branches. It is punishing when merging. Feature toggle are better from this perspective.

Keep Technical Debt backlog. Be aware of what problems you have in the system. Technical Debt is just the reality. The whole ecosystem is just moving. Thinks was perfect but as the context changed it become a debt/problem/legacy.

Q: How to deal with Code monkeys developing something fast but incorrectly vs other developers who are slow but right and tidying up debt as they go:
Good, solid coder producing good code slowly? Tracking the wrong thing. Typing speed is not a productivity indicator. Programming is a creative kind of work. Pair the slow with fast typers to find balance of quality and speed together.

Most company focus on such a thing like salaries. Like oxygen. Once you have enough it will not be a motivator.

Developers like autonomy on their decision. Giving people more control on their work helps.

Be more like a product base team instead of project based team with good success.

As an architect you have to carefully check metawork (see before) when too much autonomy is given.

High performant team: Nobody knows the secret. Nobody knows how to measure productivity. (OT - actually not true. Team level productivity is clear; individual productivity is the problem - team includes those who are providing requirement :) so all stakeholders :))

Scrum : In fact every project is a marathon not a series of sprint. You could not split a marathon to sprints Sometimes you have to step back and chang and restructure things.

In practice it is very difficult to find what is working and what is not working. Tech Radar helps to discover based on experience. It helps to break from your personal technology bubble. (AKA. learn from others experience)

Every problem is always a people problem. This is a fundamental problem in software.

“Avoid yesterday’s beasts”:
Yesterday’s best practice become today anti-patterns. Most people think anti-pattern is a synonym to “bad”. But instead: it is something initially looked as good idea then turned out to be terribe one, after the fact.

One of the problem is constantly shifting ecosystem we have deal with. Even if you do not change a single bit the entire world is changing around. So even a perfect decision today could be invalidated just because the entire software ecosystem is changing in way we could anticipate. (Subject of evolutionary architecture) (OT- changeability of system is essential goal in the architecture)

“Unknown unknowns” matter the most.

Failure source:

(OT: For this the architect should be kept in the system the longest, even if he is the most expensive resource, he is the guarantee of the consistency and the responsiveness to the changes)

Microservices are slowly reimplementing everything what we have in CORBA (or SOAP stuff later) because then need to meet the same challenges.

Patterns are repeating themselves.

Pair with existing (good) architect to see whether you like (when you want to be an architect).

Learn architecture pattern books. How to put systems together.

Sep 10, 2017
comments powered by Disqus

Links

Cool

RSS