tag:blogger.com,1999:blog-1753159697685577828.post4689433134941791691..comments2024-03-24T04:22:06.682-05:00Comments on Sharpening Stones: Complexity = Agile Simplicitypaulboalhttp://www.blogger.com/profile/04538353186298001829noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-1753159697685577828.post-70659807148474703642014-01-23T20:41:57.641-06:002014-01-23T20:41:57.641-06:00nice one! The first agile hacker of modern history...nice one! The first agile hacker of modern history to stress simplicity was Henry David Thoreau. He invented the phrase: "simplify. simplify. simplify." and then later changed it to "simplify!" ... he also had a neckbeard! :-)<br />(http://thequickword.wordpress.com/2014/01/23/on-the-origin-of-the-modern-neckbeard-hacker/)<br /><br />:-)<br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1753159697685577828.post-29809073373417006402010-04-25T19:30:43.917-05:002010-04-25T19:30:43.917-05:00Roger, thanks for the great comment! That was a v...Roger, thanks for the great comment! That was a very articulate way of describing something that I've always found challenging in software quality. I think the fact that software doesn't waste raw materials when it's done wrong (as would a traditional field involving physical products) and the low barriers to entry into the field (we teach gradeschoolers to program) are also major drivers of low quality software solutions. You're right that the culture has to shift in order for the engineering principles to further develop.<br /><br />In my post, I was also thinking about business operations -- another place where I personally think engineering principles could play a much stronger role. :D<br /><br />Thanks again for the great commentary!paulboalhttps://www.blogger.com/profile/04538353186298001829noreply@blogger.comtag:blogger.com,1999:blog-1753159697685577828.post-57094540808495208922010-04-25T13:21:40.255-05:002010-04-25T13:21:40.255-05:00Also if you really want to check out an excellent ...Also if you really want to check out an excellent series on complexity go here.<br /><br />http://nirmukta.com/complexity-explained-the-complete-series-by-dr-vinod-wadhawan/Roger Toennishttps://www.blogger.com/profile/04978765305797253741noreply@blogger.comtag:blogger.com,1999:blog-1753159697685577828.post-33393914022220026242010-04-25T09:02:38.928-05:002010-04-25T09:02:38.928-05:00Paul,
Good post.
Clearly, from your post here, yo...Paul,<br />Good post. <br />Clearly, from your post here, you have an intuitive sense of something missing in how SW design/development is practiced.<br /><br />Your observation that "Complexity = Agile Simplicity" is very insightful and is in fact a mathematically proven concept. <br /><br />As an Electrical Engineer with career focus in control systems engineering and complex adaptive systems, one of the core principles I was trained on at university was, "manageable complexity" is achieved only via the intelligent construction of systems that leverage complexity by building small, manageable "controllable" building blocks.<br /><br />These blocks then, when interacting together as designed, produce what is called "Emergent Complexity". "Emergently complex" systems are the only kind of complex systems that can be managed/controlled effectively as it grows in scale. Systems designed in this fashion allow the engineer to mathematically model, in a deterministic fashion, the behavior of those systems. If you can model it mathematically you can control it.<br /><br />If the above sounds very much like what Object Oriented Analysis and Design techniques were/are trying to accomplish in the SW arena it's because OOAD came out of the failures of prior SW design techniques to produce manageable, controllable code bases.<br /><br />The thing OOAD missed though, and still is missing, is the mathematical underpinnings for why OO concepts like encapsulation of data with function and polymorphism are effective.<br /><br />Those mathematical underpinnings are well understood and reside in the field of Linear Systems Theory mathematics and the related "Control Systems" theory and methods. These allow a designer to precisely and in deterministic fashion create controllable physical systems and controllable software systems. (See http://en.wikipedia.org/wiki/LTI_system_theory and http://en.wikipedia.org/wiki/State_space_(controls))<br /><br />These are the techniques that allow engineers to design controllable systems that, for example, make unstable airframes for an advanced aircraft stable and controllable in flight. <br /><br />The problem that still exists in the software industry is the majority of SW practitioners have no formal training in how to design software systems using the knowledge that has now existed in control theory mathematics and engineering for over 100 years.<br /><br />Agile development and OO principles represent all the tools needed to create stable, manageable and flexible software systems that can grow and change over time.<br /><br />But without the rigor of the mathematical techniques, and expertise in applying those techniques, SW practitioners are stuck using the "craftsman", "Then a miracle happens" approach to building quality SW systems. OO and Agile make the "miracles" more likely, but they still are not sufficient to deterministically predict, and then guarantee, quality outcomes in SW. <br /><br />Most who write software today, even if they embrace Agile and OO, are still "craftsman" versus "engineers". Most degrees ever granted in software would be more accurately titled as a "Bachelor of Arts" versus a "Bachelor of Science".<br /><br />Until the software industry embraces math/engineering-style rigor, and moves from being a "Then a miracle happens" craft to a truly engineering-style discipline, software will not progress to the next stage, "state in space", of it's evolution.<br /><br />Cheers,<br />RogerRoger Toennishttps://www.blogger.com/profile/04978765305797253741noreply@blogger.com