Serg

“The idea that schedules can be shortened in order to reduce cost or speed up delivery is a very common misconception. You‘ll commonly see attempts to require overtime or sacrifice ―less important scheduled tasks (like unit-testing) as a way to reduce delivery dates or increase functionality while keeping the delivery dates as is. Avoid this scenario at all costs. Remind those requesting the changes of the following facts:
- A rushed design schedule leads to poor design, bad documentation and probable Quality Assurance or User Acceptance problems.
- A rushed coding or delivery schedule has a direct relationship to the number of bugs delivered to the users.
- A rushed test schedule leads to poorly tested code and has a direct relationship to the number of testing issues encountered.
- All of the above lead to Production issues which are much more expensive to fix.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“As has been said elsewhere the architect is the interface between the business and the technology team, the architect must understand every aspect of the technology to be able to represent the team to the business without having to constantly refer others. Similarly the architect must understand the business in order to drive the team toward their goal of serving the business.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“I know, there really is an ‗i‘ in architecture. But it‘s not a capital ‗I‘, calling attention to itself, dominating discussion. The lower-case character fits neatly within the word. Its there only because it fulfills requirements for proper spelling and pronunciation.”
― Richard Monson-Haefel, 97 Things Every Software Architect Should Know

“I once had a very talented designer on my team. She was creative and thoughtful and happened to be the most experienced person in an important product area. Everyone on her team naturally went to her for advice on big decisions. I thought to myself, Obviously she should be a manager! When the team expanded, I asked her if she would step up into the role. She said yes, and I gave myself a hearty pat on the back for setting her up to have even more impact.

About a year later, she quit.

I’ll never forget what she told me right before she gave notice. She admitted that every morning as she lay in bed, she dreaded the prospect of going to work and managing people. As she said this, I could see that it was true. Her curious and thoughtful spark had been replaced by glassy-eyed exhaustion. Her team had issues that needed sorting through, and she was so burned out that she couldn’t muster the motivation. Her everyday responsibilities were not what she was passionate about. At her core, she was a maker; she wanted long periods of uninterrupted time to go deep on a problem and create something tangible with her hands.”
― Julie Zhuo, The Making of a Manager: What to Do When Everyone Looks to You