|
Indeed, it's very important to match the structure to the problem. I've seen real-world situations where the Charlie approach was clearly wrong - a maverick programmer that wrote a module on his own, only some light testing with end users, no peer-review, not even source control. The program was finished in record time (a month or so), looked good, apparently did what was required, users and management were delighted, he got a huge raise. "Charlie" went on holidays... and then disaster struck. He hadn't considered the impact on other systems, and a bug delayed the montly accouning closing process, costing thousands of man-hours correcting the errors. Other programmers had to go to his terminal to see the code... and found a huge hardcoded, unstructured mess. OTOH, in the same company, they hired a Java Senior Architect "Alan" to lead a module, just a little more complex that what "Charlie" had done. "Alan" spent the first few months meeting with all possible stakeholders, writing process diagrams, selecting a 4-person team, then spent a few more months building a "perfect" software architecture, an entire ORM layer over the systems he had to connect to. Then they chose a complicated Javascript framework for the frontend which none had experience with. After a year and a half (over a year over budget), they finally launched a first version... which wasn't what users needed. A year and a half later (3 years total), they finally have a working system. While he didn't get the credit "Charlie" got, everyone thinks "Alan" is some kind of guru and that he understands "hard" problems, and he's going to be given the lead (again) on an even larger project, which the company is betting several millions on. |