1 / 12

Big Ball of Mud

Big Ball of Mud. http://www.laputan.org/mud/mud.html Brian Foote and Joseph Yoder Lecture by Ralph Johnson. Big Ball of Mud.

phuc
Télécharger la présentation

Big Ball of Mud

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Big Ball of Mud http://www.laputan.org/mud/mud.html Brian Foote and Joseph Yoder Lecture by Ralph Johnson

  2. Big Ball of Mud A BIG BALL OF MUD is a haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetticodejungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.

  3. Big Ball of Mud • Throwaway code • Piecemeal growth • Keep it working (Daily build) • Shearing layers • Sweeping it under the rug (Black box) • Reconstruction

  4. Forces • Lack of time • Need something quickly • Get it done before the boss leaves • Cost • Lack of architectural experience • Lack of programming skill • Complexity of problem

  5. Typical BBoM • 100 programmers at an insurance company • Visual Basic • Average turnover – 18 months • Average education – associates degree • Technical abilities of management - low

  6. Avoiding BBoM • Up-front (Eager design?) • Powerful, experienced architect • Not the first system. Probably the fourth. • Small group of developers with plenty of time. • Behind (Lazy design?) • Relentless refactoring • Incremental development, daily build, etc

  7. sendmail vs. qmail Mail box /usr/spool/mail Local mail user Mail Transport Agent Local Remote SMTP SMTP MTA MTA

  8. qmail Local mail user Mail box /usr/spool/mail qmail-queue qmail-inject qmail-local mail queue qmail-smtpd qmail-remote qmail-send SMTP SMTP MTA MTA

  9. Advantages of qmail architecture • Simplicity and modifiability • No program is more than 1000 lines long • Easy to add new protocol • New feature is a new program • Security • Separate UIDs for different functions • Bug in one program doesn’t cause security hole

  10. Advantages of sendmail • It works • Created a standard • Security didn’t use to be a problem • Don’t solve problems you don’t have. • Make the standard, then you have time to solve other problems.

  11. How to Get Good Architecture • Have bad architecture • Learn from it • Do better next time

  12. Further reading • Worse is Better – Richard P. Gabriel http://www.dreamsongs.com/WorseIsBetter.html • Good Software Takes Ten Years – Joel Spolsky http://www.joelonsoftware.com/articles/fog0000000017.html

More Related