Welcome to SAC, a personal initiative to quietly transform the way we build systems. SAC stands for Simple Accessible Code and is based on the principle that developers of software systems should be able to understand the complete body of code in their systems. Complete body of code includes the operating systems and the languages and tools used to construct the applications. It stresses straightforward languages, tools and operating systems. It stresses having source for each aspect of the system, applications, tools, languages and operating systems available to all developers -- true open source! For a given project at least two of the developers should understand the entire system from operating system to language(s) to tools to applications. Why two? Redundancy.
This idea has been brewing in my mind for years. I am increasingly appalled at the complexity of languages, operating systems and tools. This has ostensibly been done in the name of productivity and capability, yet it has left us with unreliable, buggy, infiltration-prone, inefficient and incomprehensible systems. It is time for a sea change and I hope SAC contributes to this movement.
The final push to make these still formative ideas public was stumbling on C code for Rivest's RC4 stream cipher algorithm in Kaufman, Perlman and Speciner's, Network Security: Private communication in a public world, Prentice Hall, 2002, isbn=0-13-046019-2. It was less than 30 lines of C code!
The magnitude of this task makes it aspirational for the moment, but I hope to push it as far as possible in the remaining (hopefully many) active years of my career. My plan is to support it with a web site, a separate blog and publications. I have some heuristics in the works and will keep you posted on their progress. My notional schedule due to current obligations is to establish the web site by June. I will provide you with monthly progress reports.
I know February has been a slow month for my posts, but I consider this to be a very significant one. As always I would appreciate our thoughts on this new adventure. Later!
I whole-heartedly agree with the Simple Accessible Code principle. I've recently posted a Logbook on my own blog which draws a parallel between centuries old political complexity and the current state of the art of software engineering.
Check out:
http://www.metaphrast.com/rob/logbook/2006/03/common-sense-applies-to-software.html
-Rob
Posted by: Rob Van Dyk | March 19, 2006 at 02:45 PM
SAC seems to also promote documentation of code, applications, tools, methodologies, requirements of not only the development view, but all 4+1 views. From personal experience, not having SAC greatly increases the complexity and effort needed to upgrade, maintain, and interface with legacy systems, especially when none of the original developers are still around.
The one drawback I perceive is when this is applied to an agile environment. Often is the case that documentation is non existent or lacking (or dated) in agile environments. I am personally trying to implement some light documentation standards at my current environment, as I believe the COTS tools available(i.e. dyoxgen) reduce the weight of the argument of documentation being to cumbersome in agile environments.
-Vikash Dat
Posted by: VIkash Dat | June 28, 2009 at 08:01 PM