The recent Podcast with Martin Fowler caught my attention. He talked about his second edition of “Refactoring” book. And he talked about how he presents the refactoring patterns in his second edition. The first edition was mainly focused around Java samples with a tendency on class- and object-oriented patterns, but refactoring is not limited to that. Two major changes were made:
2) But an even more interesting change from an architects perspective is, that instead of UML diagrams, almost exclusively code examples are used to describe the refactoring patterns. …
Software estimation is hard. Estimating with different people is even harder.
Business sponsors, customers, users, etc. are always keen to know more about their products or projects. Especially, they are interested in when things are ready. With estimations, we are able to answer these questions (more or less accurate). And with more data and experience forecasts are getting better over time.
As a developer or software architect we often estimate. And today, we talk about the soft site of the problem (people), which is from my point of view more problematic.
Scenario #1: Let’s assume, we know quite well how long it will take. Then a manager, client or business sponsor comes into the room and claims: “Not acceptable. Think again. We need to deliver faster.” If not handled properly, we will run into an uncomfortable situation, where we negotiate the estimate. We will somehow say, that we can deliver faster. …