When a house is built, the engineer first builds its plan and then a model. Once all the stakeholders are satisfied with the model, then they go about constructing the actual house. However, in the software industry, design is neglected. It may seem that the cost of a design alteration in software is not much, but it is enormous. It acts as a butterfly effect. Catching bad design choices early is every architect’s dream. But it doesn’t happen with software, for several reasons. First, once the design choices are described and laid out, several developers start to implement the design, much as workers keep working to make a house. However unlike working on a house, software developers check in their code after a code review. No design review happens beforehand—it’s unclear what the design review expectations would be. So, developers check in code that may work but that may be far outside the design choices made initially. Thus over time, as the codebase grows bigger and bigger, the design deviates from one part of the product to the other. If the overall code were compared to a huge castle, the architecture from one part of the castle to the next would be very different.
Bitte loggen Sie sich ein, um Zugang zu diesem Inhalt zu erhalten
Unternehmen haben das Innovationspotenzial der eigenen Mitarbeiter auch außerhalb der F&E-Abteilung erkannt. Viele Initiativen zur Partizipation scheitern in der Praxis jedoch häufig. Lesen Sie hier - basierend auf einer qualitativ-explorativen Expertenstudie - mehr über die wesentlichen Problemfelder der mitarbeiterzentrierten Produktentwicklung und profitieren Sie von konkreten Handlungsempfehlungen aus der Praxis. Jetzt gratis downloaden!