I read the really valuable Skin in the game, by Nassim Taleb a few months ago. If you haven't read it yet, you might ask who are people without ski...
For further actions, you may consider blocking this person and/or reporting abuse
Great read, thanks!
I was thinking about the system architects problem and it seems that the main problem is that their work is directly passed to the implementation team. From point of view of static testing, their work has to be evaluated via review. At least as a walkthrough.
That way their poor work quality will be noticable earlier, than relying on the outcome analysis - dynamic testing.
Just curious who is responsible for reviewing the architects work? Senior most devs in the company?
Say what if the Architect is on contract basis?
🤔
At that level it becomes a collaborative effort. Usually you will have an architect, designer, product person and a senior dev or two doing the initial design. Product person defines requirements, architect defines the overarching system (backend, frontend, any middleware, etc), designers will work on the frontend design and those senior devs are working with the architect to make sure the architecture is feasable.
So when you're at that level, it's less about "I report to X", and more of "we need to build a consensus between X, Y and Z stakeholders"
I think it can help if the architect is part of the team developing the product and not part of a different entity that is responsible only for "architecting". If the architect is part-time developing then both the feedback loop is much shorter and he'll have to eat what he cooked, so he'll try to do his job as good as he can.
It would be the project owner's or coordinator's responsibility to organize a review for the architecture or specification. The process wouldn't differ much, whether an inhouse senior developer designed the architecture or a contracted one did it.
As for the process itself, it could either be a walkthrough or more formally a technical review. The organisator would call together a temporary team of reviewers (they could be anyone with a useful input - developers, software analysts, end user representative etc) and have the reviewers independently check the architecture design for comments or flaws. If any are found, the design is sent back to the author for improvements.
As a developer if you notice consistent poor design documents, best you could do is have a talk with higher ups about possibility of improving the process by intruducing a review phase for design documents.
For more information and reference: astqb.org/resources/
I think that's a fair point. I always discourage people from working too much. One should not do unpaid overtime, but I think we should do our best in those X hours that we are paid for. Partly because of professional pride, partly because I think that if you do your best, you'll grow more and you can get a better next hop.
Interesting post, Sandor.
I don't have experience with that kind of environments yet, I have only worked in association with my university and the team, fortunately, is full of committed people.
So I'm curious to know the experience of anyone reading this: when you have to deal with people that don't put their skin in the game, how do you know when it's not worth it compensating that lack of effort? I mean, I guess that the maintenance they don't make is going to need compensation from others in the team that actually need things to go well. What's your experience drawing limits? At what cost?
Thanks for your post!
Another fantastic article. Thanks for the mention. Always enjoy reading your articles.
Thanks a lot for your kind words! This article would have never been written without your contribution!
Thanks
Thanks for your kind words, Greg!
True, and these managers have one more ace in their hands, change the name of the team early on!