|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
|
... ... ... For a given level of function, however, that system is best in which one can specify things with the most simplicity and straightforwardness. Simplicity is not enough. Mooers's TRAC language and Algol 68 achieve simplicity as measured by the number of distinct elementary concepts. They are not, however, straightforward. The expression of the things one wants to do often requires involuted and unexpected combinations of the basic facilities. It is not enough to learn the elements and rules of combination; one must also learn the idiomatic usage, a whole lore of how the elements are combined in practice. Simplicity and straighforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity. Frederick P. Brooks, Jr.: The Mythical Man-Month. Addison-Wesley, Reading MA, 1995 (anniversary ed.) To me, development consists of two processes that feed each other. First, you figure out what you want the computer to do. Then, you instruct the computer to do it. Trying to write those instructions inevitably changes what you want the computer to do and so it goes.In this model, coding isn't the poor handmaiden of design or analysis. Coding is where your fuzzy, comfortable ideas awaken in the harsh domain of reality. It is where you learn what your computer can do. If you stop coding, you stop learning. We aren't always good at guessing where responsibilities should go. Coding is where our design guesses are tested. Being prepared to be flexible about making design changes during coding results in programs that get better and better over time. Insisting that early design ideas be carried through is short sighted. Kent Beck: Smalltalk Best Practice Patterns. Prentice Hall, NJ 1997
|
There are a lot of quality general architectural resources available from the Net, therefore the list below represent only some links that I am interested personally. The stress here is on skepticism and this collection is neither complete, nor up to date. But still it might help students that are trying to study this complex and interesting subject. Or perhaps, if you already a software architect you might be able to expand your knowledge of the subject.
The primary purpose of Software Architecture courses is to teach students some higher level skills useful in designing and implementing complex software systems. In usually includes some information about classification (general and domain specific architectures), analysis and tools. As guys in Breadmear consulting aptly noted in their paper Who Software Architect Role:
A simplistic view of the role is that architects create architectures, and their responsibilities encompass all that is involved in doing so. This would include articulating the architectural vision, conceptualizing and experimenting with alternative architectural approaches, creating models and component and interface specification documents, and validating the architecture against requirements and assumptions.
However, any experienced architect knows that the role involves not just these technical activities, but others that are more political and strategic in nature on the one hand, and more like those of a consultant, on the other. A sound sense of business and technical strategy is required to envision the "right" architectural approach to the customer's problem set, given the business objectives of the architect's organization. Activities in this area include the creation of technology roadmaps, making assertions about technology directions and determining their consequences for the technical strategy and hence architectural approach.
Further, architectures are seldom embraced without considerable challenges from many fronts. The architect thus has to shed any distaste for what may be considered "organizational politics", and actively work to sell the architecture to its various stakeholders, communicating extensively and working networks of influence to ensure the ongoing success of the architecture.
But "buy-in" to the architecture vision is not enough either. Anyone involved in implementing the architecture needs to understand it. Since weighty architectural documents are notorious dust-gatherers, this involves creating and teaching tutorials and actively consulting on the application of the architecture, and being available to explain the rationale behind architectural choices and to make amendments to the architecture when justified.
Lastly, the architect must lead--the architecture team, the developer community, and, in its technical direction, the organization.
Again, I would like to stress that the main principle of software architecture is simple and well known -- it's famous KISS principle. While principle is simple its implementation is not and a lot of developers (especially developers with limited resources) paid dearly for violating this principle. I have found one one reference on simplicity in SE: R. S. Pressman. Simplicity. In Software Engineering, A Practitioner's Approach, page 452. McGraw Hill, 1997. Here open source tools can help because for those tools a complexity is not such a competitive advantage as for closed source tools.
I appreciate am architecture of software system that lead to small size implementations with simple, Spartan interface. In these days the usage of scripting languages can cut the volume of code more than in half in comparison with Java. That's why this site is advocating usage of scripting languages for complex software projects.
"Real Beauty can be found in Simplicity," and as you may know already, ' "Less" sometimes equal "More".' I continue to adhere to that philosophy. If you, too, have an eye for simplicity in software engineering, then you might benefit from this collection of links.
I think writing a good software system is somewhat similar to writing a multivolume series of books. Most writers will rewrite each chapter of book several times and changes general structure a lot. Rewriting large systems is more difficult, but also very beneficial. It make sense always consider the current version of the system a draft that can be substantially improved and simplified by discovering some new unifying and simplifying paradigm. Sometimes you can take a wrong direction, but still "nothing venture nothing have."
On a subsystem level a decent configuration management system can help going back. Too often people try to write and debug their fundamentally flawed architecturally "first draft", when it would have been much simpler and faster to rewrite it based on better understanding of architecture and better understanding of the problem. Actually rewriting can save time spend in debugging of the old version. That way, when you're done, you may get easy-to-understand, simple software systems, instead of just systems that "seems to work okay" (only as correct as your testing).
An interesting note about programming as art form can be found at The GNU-Linux Art Farm - 08-30-99
On component level refactoring (see Refactoring: Improving the Design of Existing Code) might be a useful simplification technique. Actually rewriting is a simpler term, but let's assume that refactoring is rewriting with some ideological frosting ;-). See Slashdot Book Reviews Refactoring Improving the Design of Existing Code.
I have found one reference on simplicity in SE: R. S. Pressman. Simplicity. In Software Engineering, A Practitioner's Approach, page 452. McGraw Hill, 1997.
Another relevant work (he try to promote his own solution -- you can skip this part) is the critique of "the technology mud slide" in a pretty interesting book by Harvard Business School Professor Clayton M. Christensen is very relevant. He defined "technology mudslide" very similar to Brooks "software development tar pit" -- a perpetual cycle of abandonment or retooling of existing systems in pursuit of the latest fashinable technology trend -- a cycle in which
"Coping with the relentless onslaught of technology change was akin to trying to climb a mudslide raging down a hill. You have to scramble with everything you've got to stay on top of it. and if you ever once stop to catch your breath, you get buried."
The complexity caused by adopting new technology for the sake of new technology are further exacerbated by the narrow focus and inexperience of many project leaders -- inexperience with mission-critical systems, systems of scale, software development disciplines, and project management. A Standish Group International survey recently showed that 46% of IT projects were over budget and overdue -- and 28% failed altogether. that's normal and probably the real figures are much lower: great software managers and architects are rare and it is those people who determine the success of a software project.
"Attention! Throw out those other improvement methods - we have just discovered the best ever. With our method, your quality will go up and costs and cycle time will go down." Almost any improvement method is hailed as the best way to save business from problems when it is new. Unfortunately, a few years later, this same method is now the reviled, flawed method that a new method is replacing. This parable tells how this happens.
In the 17th century, Europeans believed that silver bullets could kill werewolves. Today's executives seek silver bullets to protect themselves not from werewolves but from sliding profits, disillusioned stockholders, and lost market share. The silver bullets for our executives are those new management trends that promise to transform the way business is done.
Examples over the decades have included Management by Objectives and Total Quality Management, while Six Sigma, Lean Enterprise, the Capability Maturity Model Integration (CMMI®), and agile software development techniques are more recent methods earning silver-bullet reputations.
Process improvement initiatives like these can and do work, but how they are implemented is critical to their success. The following parable shows the 11 phases in the life cycle of such an improvement initiative.
Phase 1: Fresh StartAn executive of Porcine Products, Mr. Hamm, decides to throw away all silver bullets. He decides that no one knows his company like he does. He takes a close look at how the company is working to determine what its problems are and how they arose. He also looks at company strengths to leverage them and make them more effective in the future.
Envision a little pig in a suit, wiping a bunch of architectural drawings and books off a table.
Phase 2: Executive Dedication and OpennessHamm makes it his single-minded focus to improve Porcine Products. Having identified its problems and strengths and determined how to address them, he dedicates time and money to implementing the identified improvements and eliminating conflicting initiatives. He hires forward-thinking, intelligent managers and devotes considerable amounts of his own time to be sure that the problems are truly solved, not just glossed over. Hamm and his managers research a number of current and future improvement methods to help define current problems and to be potential tool kits providing applicable suggestions.
The executive insists that the senior managers become part of the solution. Hamm forces them to examine their roles in contributing to company problems and to restructure their own work to change the way the company operates. A climate of openness without retribution is fostered, and senior managers listen to messages from all levels of the company, especially messages suggesting improvements in their own work.
Envision a little pig constructing a house made of bricks.
Phase 3: SuccessPorcine Products reaps the rewards of this thorough effort. Executives and managers change the way they lead. Cross-company improvements change the way the company operates. Products are created more efficiently and have better quality. Costs go down, orders increase, and morale improves.
Phase 4: PublicityThe business press notices the successes of Porcine Products. Hamm explains the improvements his company has achieved and is asked for a name for his method. In honor of his French grandfather, he calls the improvement Balle-Argentee. The press also wants to report how much time and money was spent, and what was reaped from the improvements; Hamm looks back and makes estimates. From these the business press calculates the magic return-on-investment (ROI) number for the Balle-Argentee method of business improvement.
Envision a little pig proudly holding a book showing a house of bricks on the cover. The book's title is "The Balle-Argentee Method."
Phase 5: MomentumOther companies look eagerly at the success of Porcine Products. Some of them are experiencing a competitive disadvantage because Porcine Products is now working more effectively than their own company, while others want to achieve the publicized ROI. Discussions at meetings of executives focus on what Porcine Products did, and why it worked.
Phase 6: First ReplicationExecutives at these other companies decide they want to reproduce Porcine Product's success. They talk with Hamm and others in his company about what actually happened. Each company assigns a senior manager to oversee the implementation of this improvement method across the companies. These senior managers carefully read the literature about the Balle-Argentee method. Implementers look at their own companies' problems and seek to implement the spirit as well as the letter of the Balle-Argentee approach. When they make recommendations, they listen to suggestions for improvement in their own work. They keep close watch on expenditures and benefits of this approach so they will be able to report their ROI.
Envision two or three other little pigs constructing house of wood.
Phase 7: ConfirmationSome of these companies publish studies of their own success using the Balle-Argentee method. The studies cite the specific improvements each company decided to make. Because of the attention paid to investments and returns since the adoption of Balle-Argentee, this set of companies can cite precise ROI figures. These companies earn accolades from shareholders for fiscally effective management. General business books about this method are published, including "Balle-Argentee in Warp Time," and "Balle-Argentee for Small Companies."
Envision a collection of books with houses of wood on the cover.
Phase 8: ProceduralizationMany more companies decide that this method is valuable. The ROI convinces some, and the fact that their competitors are reaping the returns from Balle-Argentee convinces the rest. With this second set of companies, the executives and senior managers add Balle-Argentee as one more method in their current process initiatives. Because they cannot adequately focus on all of the methods, they delegate implementation of the Balle-Argentee effort to middle managers. These middle managers are given ROI goals that match the published numbers. Other middle managers are given comparable ROI goals for simultaneously implementing different process improvement efforts. Executives believe that the competition engendered by these multiple initiatives will increase the fervor in implementing all the initiatives.
What the implementing managers know about the Balle-Argentee method is limited to the published results. Time constraints prevent these managers from contacting Porcine Products or from reading any of but the shortest summary articles. To reduce the risk of missing their ROI goals, the managers seek ways to improve the cost-effectiveness of Balle-Argentee as they implement it. Implementation that took Porcine Products several years must now be completed within a fiscal cycle. The implementing managers require their people to use some of the specific improvements described in the literature exactly as they are described, without costly discussion or modification. Other specific improvements are ruled out because they would be costly to implement. The stated rationale is that these improvements will not work here because company circumstances differ.
Instead, the implementing managers restate general strategies in the Balle-Argentee literature as broad goals, which they then apply in a sparing manner. In almost all cases, the imperative for executives and managers to listen to workers and to change their own work accordingly is the first general strategy to be deleted. It is restated as improve communication and then becomes implemented as improve communication downward. These implementing managers have risen in their companies because they respect the wisdom of their superiors. They do not ask for literal implementation of the strategy executives must listen more because to do so might cause their superiors to feel threatened or embarrassed.
Finally, these implementing managers seek to cast their own actions in the best light. They believe involving executives would signal weakness. Much of the implementation of Balle-Argentee shifts to managing the news. Executives and senior managers remain uninformed and are uninvolved in the improvement effort except in expecting to reap benefits.
Envision an entire village of houses made of straw.
Phase 9: Diminished ReturnsBecause of cost cutting, time compression of the improvement effort, lack of executive involvement, dilution of emphasis due to other improvement initiatives, and a tendency to apply the steps as a checklist rather than to seek and fix the company's basic business problems, these more recent Balle-Argentee improvement efforts do not reap the published ROI numbers. This happens broadly across the industry.
Envision the village of straw houses starting to crumble, propped up by sticks and invaded by mice.
Phase 10: Blaming the MethodWorkers in these companies feel bombarded by misunderstood management initiatives, and Balle-Argentee is applied intrusively asking for additional work in order to claim compliance. Workers know that the checklists they are being asked to follow and fill out are not solving any real problems. Some attend conferences and complain that the Balle-Argentee method makes companies do stupid things. They cite their experiences, complaining that the Balle-Argentee sponsor does not want to hear about any real problems that are not quickly solved. They complain that checklists and complex documentation substitute for investigation and solutions, and that the intense focus on the ROI severely decreases the investment money for making complex improvements rather than applying Band-Aids.
Coupled with the evidence from Phase 9 that current implementations of Balle-Argentee do not provide good ROI, these very real complaints cause the business press to be ruthless in denigrating Balle-Argentee as a flawed approach. Articles appear advocating slaying the Balle-Argentee monster.
Envision the big bad wolf blowing down the village of straw houses.
Phase 11: Starting FreshMr. Boar, a true improvement-minded executive at Animalia, Inc., decides that no one knows his company like he does. He decides to throw out Balle-Argentee along with all the other silver bullets and takes a close look at Animalia's problems and how to fix them.
Envision a different little pig wiping a bunch of books and drawings off his desk. One of the books has a picture of a house of bricks on the cover.
Morals of the StoryHow to Use Silver Bullets
- A sequence of steps, each consisting of decisions made for good reasons, does not necessarily lead to a good result. In the parable, each executive and manager was making good decisions within the constraints established by those higher up. The end result was disastrous.
- For best results, start at Phase 1 and stop at Phase 3.
- Only by really looking at your company's problems can you solve them. Other people's strategies worked for them because the strategies were made for them. If you want to make real improvements, you have to do the work of determining your business problems and applying methods that make sense to fix them.
- Do not assume that people who claim to be using a method really are using it. In Phase 8, actual use of the original method ceases. Instead we have a method bearing the same name that attempts to reap results quickly and dirtily, and is thoroughly unsuccessful in doing so. (Unfortunately, Phase 8 is also where most companies try to use the method.)
- There is nothing like the original. Do not read everyone else's interpretation of a method, read the original. If possible, talk to the creator. Find out the principles behind the steps, so you can ensure your adaptation is consistent with the principles.
- The ROIs of multiple improvement initiatives do not add; they interfere. Focus on what problems you want to solve, and work out as executives how the initiatives contribute to solutions. Determine where the initiatives will appear as conflicting to the workers and reconcile them. Display a unified front to the workers.
- Do not assume other companies' ROI numbers will apply to you. They started from a different place and made different investments [1].
A great deal has been written about the appropriate way to do process improvement. You must focus on the business goal of improvement, not just on the method used to get there (e.g., CMMI) or on intermediate indicators (e.g., Level 3) [2, 3]. Executives must devote the appropriate resources and stay involved [4]. Managers must learn what is real and react appropriately [5, 6]. The process group must analyze the real causes of problems [7], plan changes, get them approved, and make sure the organization follows through [8]. And everyone must make sure the changes actually improve the product development processes, not interfere with them.
Specific guidance on how to avoid making mistakes with a silver bullet follows:
Special Credit
- Everyone: Realize that all methods are a means to the end of an improved company, not the end themselves. You cannot paste on improvements - you have to look at how your company is working right now and how any given method will alter that.
- Executives: You have the responsibility to develop your own understanding of what is impeding your company's path to a better future and determining what steps will remove those barriers. Take time to understand any externally generated initiative before pushing it. Does your company even have the same problems as the companies that succeeded with the method?
Understanding your true problems requires upward communication. Know what currently makes upward communication unsafe, particularly, do your managers have incentives to tell you only good news [9, 10]? Find out what happens to bad news and where it stops. Find a way around that barrier or you will not hear what is really happening in your company.
- Managers: You have to understand the method(s) you are pushing. Needing something really badly does not mean you can get it faster by means of wishing or whipping. Determine what is realistic and do not ask for shortcuts.
Insist on understanding the relationship between initiatives that compete for people's attention. Clarify that relationship, coordinate with other sponsors, and make it easy for the workers to comply with all of the initiatives. Your products make the money, not your management initiatives. You have to be sure the initiatives do not make it difficult to make the product!
- Process Groups: Push back on managers demanding the same results as other companies but in less time, with fewer resources, and with less thought. Point out why it is not going to happen. Then propose something that will work. Do not compound the problem by giving only the good news.
- One Last Word: A truly successful effort will result when a company develops specific solutions to its specific concerns. Second-generation applications of these methods can work if they are studied to determine where the true benefits came from, and applied intelligently with appropriate investment. But a house of straw is erected when companies believe they can quickly gain return from low-budget adherence to someone else's solutions.
Special thanks goes to Cathy Kreyche for her contributions to this article.
References
- Sheard, Sarah A., and Christopher L. Miller. The Shangri-La of ROI. Proc. of the 10th Annual Symposium of the International Council on Systems Engineering, Minneapolis, MN, July 2000.
- Sheard, Sarah A. What Is Senior Management Commitment? Proc. of the 11th Annual Symposium of the International Council on Systems Engineering, 2001. Republished in Proc. of the Software Technology Conference, Salt Lake City, UT, 2002.
- Kaplan, Robert S. "Implementing the Balanced Scorecard at FMC Corporation: An Interview with Larry D. Brady." Harvard Business Review Sept.-Oct. 1993.
- Gardner, Robert A. "10 Process Improvement Lessons for Leaders." Quality Progress Nov. 2002.
- Gilb, Tom. "The 10 Most Powerful Principles for Quality in Software and Software Organizations." CrossTalk Nov. 2002.
- Baxter, Peter. "Focusing Measurements on Managers' Informational Needs." CrossTalk July 2002: 22- 25.
- Card, David. Learning From Our Mistakes With Defect Causal Analysis. Proc. of the International Conference on Software Process Improvement, Adelphi, MD, Nov. 2002.
- Bowers, Pam. "Raytheon Stands Firm on Benefits of Process Improvement." CrossTalk March 2001: 9- 12.
- Argyris, Chris. Overcoming Organizational Defenses: Facilitating Organizational Learning. Prentice Hall, 1990.
- Argyris, Chris. Flawed Advice and the Management Trap. New York: Oxford UP, 2000.
About the Author
Sarah A. Sheard is technical lead for Systems Engineering at the Software Productivity Consortium. She has more than 20 years of experience in systems engineering and process improvement. Sheard has published more than 20 articles and papers on systems engineering and process improvement in CrossTalk, the proceedings of software technology conferences, International Council on Systems Engineering (INCOSE) symposiums, and the INCOSE journal. Sheard received INCOSE's "Founder's Award" in 2002. As the consortium's technical lead for the Capability Maturity Model Integration (CMMI®), Sheard was the lead author of the Software Productivity Consortium's course on "Transitioning to the CMMI."
Software Productivity Consortium
Phone: (703) 742-7106
Fax: (703) 742-7350
E-mail: sheard@software.org
Posted by Jeremy on Friday, September 30, 2005 - 20:14In a conversation that began as a request to include the SAS Transport Layer in the mainline Linux kernel, there was an interesting thread regarding specifications. Linux creator Linus Torvalds began the discussion saying, "a 'spec' is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality."
Linus went on to list two reasons to avoid specifications when writing software. First, "they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW." Second, "specs have an inevitable tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP." As a "classic example" he pointed to the OSI model, "we still talk about the seven layers model, because it's a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it's a way to _talk_ about things, not to implement them. And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software."
From: Linus Torvalds [email blocked] To: Arjan van de Ven [email blocked] Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel Date: Thu, 29 Sep 2005 12:57:05 -0700 (PDT)On Thu, 29 Sep 2005, Arjan van de Ven wrote:
>
> a spec describes how the hw works... how we do the sw piece is up to
> us ;)How we do the SW is indeed up to us, but I want to step in on your first
point.Again.
A "spec" is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate.
And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality.
So there's two MAJOR reasons to avoid specs:
- they're dangerously wrong. Reality is different, and anybody who thinks specs matter over reality should get out of kernel programming NOW. When reality and specs clash, the spec has zero meaning. Zilch. Nada.
None.It's like real science: if you have a theory that doesn't match experiments, it doesn't matter _how_ much you like that theory. It's wrong. You can use it as an approximation, but you MUST keep in mind that it's an approximation.
- specs have an inevitably tendency to try to introduce abstractions levels and wording and documentation policies that make sense for a written spec. Trying to implement actual code off the spec leads to the code looking and working like CRAP.
The classic example of this is the OSI network model protocols. Classic spec-design, which had absolutely _zero_ relevance for the real world. We still talk about the seven layers model, because it's a convenient model for _discussion_, but that has absolutely zero to do with any real-life software engineering. In other words, it's a way to _talk_ about things, not to implement them.
And that's important. Specs are a basis for _talking_about_ things. But they are _not_ a basis for implementing software.
So please don't bother talking about specs. Real standards grow up _despite_ specs, not thanks to them.
Linus
From: Luben Tuikov [email blocked]
Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
Date: Thu, 29 Sep 2005 16:20:13 -0700 (PDT)--- Linus Torvalds [email blocked] wrote:
>
> A "spec" is close to useless. I have _never_ seen a spec that was both big
> enough to be useful _and_ accurate.
>
> And I have seen _lots_ of total crap work that was based on specs. It's
> _the_ single worst way to write software, because it by definition means
> that the software was written to match theory, not reality.A spec defines how a protocol works and behaves. All SCSI specs are currently very layered and defined by FSMs.
This is _the reason_ I can plug in an Adaptec SAS host adapter to Vitesse Expander which has a Seagate SAS disk attached to phy X... And guess what? They interoperate and communicate with each other.
Why? Because at each layer (physical/link/phy/etc) each one of them follow the FSMs defined in the, guess where, SAS spec.
If you take a SAS/SATA/FC/etc course, they _show you_ a link trace and then _show_ you how all of it is defined by the FSM specs, and make you follow the FSMs.
> So there's two MAJOR reasons to avoid specs:
Ok, then I accept that you and James Bottomley and Christoph are _right_, and I'm wrong.
I see we differ in ideology.
> It's like real science: if you have a theory that doesn't match
> experiments, it doesn't matter _how_ much you like that theory. It's
> wrong. You can use it as an approximation, but you MUST keep in mind
> that it's an approximation.But this is _the_ definition of a theory. No one is arguing that a theory is not an approximation to observed behaviour.
What you have here is interoperability. Only possible because different vendors follow the same spec(s).
> - specs have an inevitably tendency to try to introduce abstractions
> levels and wording and documentation policies that make sense for a
> written spec. Trying to implement actual code off the spec leads to the
> code looking and working like CRAP.Ok, I give up: I'm wrong and you and James B are right.
> The classic example of this is the OSI network model protocols. Classic
Yes, it is a _classic_ example and OSI is _very_ old.
_But_ the tendency of representing things in a _layered_, object oriented
design has persisted.> spec-design, which had absolutely _zero_ relevance for the real world.
> We still talk about the seven layers model, because it's a convenient
> model for _discussion_, but that has absolutely zero to do with any
> real-life software engineering. In other words, it's a way to _talk_
> about things, not to implement them.Ok.
> And that's important. Specs are a basis for _talking_about_ things. But
> they are _not_ a basis for implementing software.Ok. Let's forget about maintenance and adding _new_ functionality.
> So please don't bother talking about specs. Real standards grow up
> _despite_ specs, not thanks to them.Yes, you're right. Linus is always right. Now to things more pertinent, which I'm sure people are interested in:
Jeff has been appointed to the role of integrating the SAS code with the Linux SCSI _model_, with James Bottomley's "transport attributes". So you can expect more patches from him.
Regards,
LubenP.S. I have to get this 8139too.c network card here working.
From: Linus Torvalds [email blocked]
Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel
Date: Thu, 29 Sep 2005 17:35:27 -0700 (PDT)On Thu, 29 Sep 2005, Luben Tuikov wrote:
>
> > It's like real science: if you have a theory that doesn't match
> > experiments, it doesn't matter _how_ much you like that theory. It's
> > wrong. You can use it as an approximation, but you MUST keep in mind
> > that it's an approximation.
>
> But this is _the_ definition of a theory. No one is arguing that
> a theory is not an approximation to observed behaviour.No.
A scientific theory is an approximation of observed behaviour WITH NO KNOWN HOLES.
Once there are known holes in the theory, it's not a scientific theory. At best it's an approximation, but quite possibly it's just plain wrong.
And that's my point. Specs are not only almost invariably badly written, they also never actually match reality.
At which point at _best_ it's just an approximation. At worst, it's much worse. At worst, it causes people to ignore reality, and then it becomes religion.
And that's way _way_ too common. People who ignore reality are sadly not at all unusual.
"But the spec says ..." is pretty much always a sign of somebody who has just blocked out the fact that some device doesn't.
So don't talk about specs.
Talk about working code that is _readable_ and _works_.
There's an absolutely mindbogglingly huge difference between the two.
Linus
From: Theodore Ts'o [email blocked] Subject: Re: I request inclusion of SAS Transport Layer and AIC-94xx into the kernel Date: Fri, 30 Sep 2005 01:31:49 -0400
On Thu, Sep 29, 2005 at 04:20:13PM -0700, Luben Tuikov wrote:
>
> A spec defines how a protocol works and behaves. All SCSI specs
> are currently very layered and defined by FSMs.A spec defines how a protocol works and behaves --- *if* it is well-specified and unambiguous, and *if* vendors actually implement the spec correctly. (And sometimes vendors have major economic incentives to cheat and either intentionally violate the specification, or simply not bother to test to make sure whether or
not they implemented their hardware correctly.)Computing history has been literred with specifications that were incompentently written and/or incompentently implemented --- from the disaster known as ACPI, to FDDI (early FDDI networking gear was interoperable only if you bought all of your gear from one vendor, natch), consumer-grade disks which lied about when data had been
safely written to iron oxide to garner better Winbench scores, and many, many, many others.This is one of the reasons why the IETF doesn't bless a networking standard until there are multiple independent, interoperable implementations --- and even _then_ there will be edge cases that won't be caught until much, much later.
In those cases, if you implement something which is religiously adherent to the specification, and it doesn't interoperate with the real world (i.e., everybody else, or some large part of the industry) --- do you claim that you are right because you are following the specification, and everyone else in the world is wrong? Or do you adapt to reality? People who are too in love with specifications so that they are not willing to be flexible will generally not be able to achieve complete interoperability. This is the reason for the IETF Maxim --- be conservative in what you send, liberal in what you will accept. And it's why interoperability testing and reference implementations are critical.
But it's also important to remember when there is a reference implementation, or pseudo-code in the specification, it's not the only way you can implement things. Very often, as Linus has pointed out, there are reasons why the pseudo-code in the specification is wholely inappropriate for a particular implementation. But that's OK; the
implementation can use a different implementastion, as long as the result is interoperable.Regards,
- Ted
Related Links:
[add new comment | printer friendly page]