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:
- understand technical aspect
- soft skills. Important to find compromised between contradicting parties with different priorities
- express architect vision to business and technical.
- understanding the different nature of knowledge: Depth of knowledge is not as important as the breadth of knowledge. Knowing multiple ways of implementing an architecture/tool is more important than knowing a single tool to implement the architecture. He has to give up certain expertise to in exchange to get more breadth. Broaden your technology knowledge.
- all these “-ilities”: knowing the broader context. Especially broader business aspect: resiliency, scalability, reliability, maintainability, etc. One of these what architects are not emphasizing enough is the feasibility. Should we even try this? Should/could we do that? Timeframe and cost constraints. Understand feasibility.
- understand how a tool might have effect on your architecture.
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.
- Pair with your team regularly
- see how architecture get to live code.
- guide junior to understand architecture
- see the problem come up in real codebase, etc.
How to transfer essential knowledge to developers
- pair programming is the best for sure.
- a kind of good specification language: certain spec language has the problem of being too tech to a non-tech and not enough tech to a programmer. UML is not a good communication language. Alternative could be C4 model might be suitable because in C4 you have think in different layers and aspect of architecture . (He is giving a summary). It is targeted to different audiences implicitly.
- Lightweight Architecture Decision Records: Text based. Capture essence why we made certain architectural decision. Put into version control. Try to capture the essence why you have made these architecture decision. Do not lose all the analysis work you have made what drive to the conclusion of the usage of current architecture. It could include simple status indication that it is an idea, approved and even that it is implemented and finally removed (as the system is evolved later and it had to change).
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.
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.
- choosing the wrong architecture what does not support what you want.
- Next shiny thing. Great way to learn new stuff probably not the most effective ways to develop good stuff.
- good architecture start degrading by people because of their own reason.
(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)
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.