Module - Design, Development and Creativity
Class or Article - Article
Lesson or Name - Foote, B. & Yoder, J. (2000) Big Ball of Mud.
IN HARRISON, N., FOOTE, B. & ROHNERT, H.
(Eds.) Pattern languages of program design
4. Addison Wesley
Additional Info - N/A
Precis
Brian Foote and Joseph Yoder present a 'Big Ball of Mud' a information technology description of a software system that lacks any particular architecture. While undesirable by software engineers, such systems are common place due to business pressure, developer turnover and code entropy. This method is popular in practice even though disliked in theory. However in saying this thee is a place for big balls of mud. They work providing companies with the ability to develop quickly at a relatively low cost.
Casual architecture can be normal during the early stages of evolution, some reasons could be that technology moves too quickly for long term architecture and in fact disposable programming is state of the art.
There are many components to big balls of mud:
Throwaway code, Piecemeal Growth, Keep it Working, Shearing Layers, Sweeping it under the Rug and Reconstruction.
Reflection
When reading this piece, while long it gave me a great insight in to technology. My previous experiences led me to believe that each project reached for architectural perfection, however understanding there is a deeper game at play really opened my eyes and it makes sense.
Effectively a big ball os mud is like building a structure out of different brands of lego that perhaps dont fit together or alternatively building with the same set but using it in a different way, using the smaller pieces instead of the bigger pieces or vice versa. While building a big ball of mud might be right at the time in the future it could become costly so a clean up process would be beneficial to take the functioning parts of a program and restructure it, writing it in good, clean code.
It is a complex world , while it works in the short term, for the long term it might be worth reconstructing or building mini developments and when you get them right, plug them in to the architecture. In essence it is like the space modules. They are built separately, potentially by different people however they all fit together and work harmoniously. Clean engineering. Maybe these two industries could teach each other how to win in both the short and long term.
Brian Foote and Joseph Yoder present a 'Big Ball of Mud' a information technology description of a software system that lacks any particular architecture. While undesirable by software engineers, such systems are common place due to business pressure, developer turnover and code entropy. This method is popular in practice even though disliked in theory. However in saying this thee is a place for big balls of mud. They work providing companies with the ability to develop quickly at a relatively low cost.
Casual architecture can be normal during the early stages of evolution, some reasons could be that technology moves too quickly for long term architecture and in fact disposable programming is state of the art.
There are many components to big balls of mud:
Throwaway code, Piecemeal Growth, Keep it Working, Shearing Layers, Sweeping it under the Rug and Reconstruction.
Reflection
When reading this piece, while long it gave me a great insight in to technology. My previous experiences led me to believe that each project reached for architectural perfection, however understanding there is a deeper game at play really opened my eyes and it makes sense.
Effectively a big ball os mud is like building a structure out of different brands of lego that perhaps dont fit together or alternatively building with the same set but using it in a different way, using the smaller pieces instead of the bigger pieces or vice versa. While building a big ball of mud might be right at the time in the future it could become costly so a clean up process would be beneficial to take the functioning parts of a program and restructure it, writing it in good, clean code.
It is a complex world , while it works in the short term, for the long term it might be worth reconstructing or building mini developments and when you get them right, plug them in to the architecture. In essence it is like the space modules. They are built separately, potentially by different people however they all fit together and work harmoniously. Clean engineering. Maybe these two industries could teach each other how to win in both the short and long term.
Quotes
Comments
Post a Comment