Ben Smith

	The concept of conceptual integrity is introduced in the essay Aristocracy, Democracy and System Design by the example of the Reims Cathedral. Unlike other cathedrals, which used new and fashionable techniques in their creation, the Reims Cathedral was created with a unified design. The author believes the individual architects of the cathedral gave up their own ideas in favor of a Cathedral with a small set of specific goals.
	The authors notes that there is a conflict between having a simple design and a large set of features. A computer without an operating system or programming language is very simple, but not easy to use because it has very little features. Operating systems and programming languages try to improve open this by adding features, but by doing this they make the system harder to learn and less unified. The author cites the PDP-10 as a small, simple system and the OS/360 as a complex system with many features. Just because something is simple does not mean it has a unified design. The author mentions the Algol programming language as something which is simple, but not easy to use because it is not straightforward. The author believes the only way a system can be both simple and have a large enough set of features is by following a unified design.
	The author believes that a project gains conceptual integrity by being designed by as few minds as possible. To allow the project to be designed by few people and created by many, the author recommends separating the architecture, or the specification of the user interface, from the the implementation. The architecture is the rules on how the system should work from the user's perspective. When designing the architecture, the designer should work in the interest of the user. An example of how architecture is different from implementation is the ease of reading a wristwatch and a clock tower after learning a clock's interface, even though they may be implemented very differently. The author showed the Fortran programming language as an example of a specification that can have many implementations, as it is possible for many differently implemented compilers to work with the Fortran specification.
	The author anticipates that a reader may accuse him of trying to focus all the creative work into a few people he calls “the aristocracy”. The author states that only accepting the ideas of a few designers is necessary because accepting all good ideas will lead to a product that is not cohesive. If the project finds that there are many good ideas that it is rejecting, it should start over with a new design that incorporates these new ideas. The also believes that the design of the system's interface is not the only creative work in a system's creation. Implementing a project well also requires creativity, and a project will not succeed if it is poorly implemented.
	One problem with designing a system's interface with a small team of people is that the majority of the team will have no work to do while specification is being created. The author states sthat this is not a problem in other fields such as construction, where it would be insane for the construction team to begin work before that architect is done with the blueprints. One solution is to only hire workers to implement the system after the specification is finished. It is also possible for the the implementation team to begin working given the same constraints as the architecture team by creating the skeleton of the project and working on tools to help when the design is done.
	I agree with this essay's message on designing software with a unified design. I believe that software that is written with a unified concept is easier and more enjoyable to use.
	When reading this essay, I thought of the two scripting languages Python and Perl as examples of systems written with and without conceptual integrity. I find that Perl included too many features in its design, while Python has very few core concepts that make it easy to learn and use without being too verbose. When writing in Perl, one needs to be very aware of the many intricacies of the language, as many actions have the side effect of triggering a feature such an implicit variable. I found that the language had many special cases and was difficult to learn.
	In contrast to Perl, I found that Python has a much more unified design. The language was designed with a small set of core features that include enough features to do most tasks easily without including any extraneous features. This is shown by some of the lines from the “Zen of Python”, a text which attempts to explain the design principles of Python. One line  states “There should be one – and preferably only one – obvious way to do it.”. This line is in contrast to Perl's motto “There's more than one way to do it, and highlights the two languages ideas on features. Perl includes as many features as possible, while python tries to stay minimal and have one best way to to any task. By the author's definition, it is clear that Python has a much more conceptual integrity.
	I also agree with the the essays statement that the task of implementation is just as creative and as the task of design. The Linux Operating System, for example, was created as an implementation of the previously designed Unix specifications. Despite doing very little work on designing specifications, the team working on Linux succeeded in creating a successful operating system.
	Additionally, I have never felt that I was not being creative when doing programming homework for my computer science classes, despite the fact that all of my assignments were written as an implementation of a specific interface. In fact, almost everything I have learned as a computer science major has been on how to implement a specification as efficiently as possible. The use of the best algorithm for a certain task
	One problem with the software design model described in the essay is that it is inflexible in regards to changing requirements and new ideas. I agree that a conceptual integrity is important, but the steps to get it are at odds with current methods of software development that focus on reacting to change. In the essay's model, the specification is created before other work is done and then remains unchanged throughout the rest of the design process. In agile design, however, the team immediately begins coding and writes specifications based on the experience and feedback from the code. Because of this, the specifications generated by agile programming are more fluid and can change in response to changing requirements and developer experience. 	The author anticipated that a project might need to incorporate new ideas, but when this needs to happen the author recommends that the team “scraps the whole system and starts again on an integrated system with different basic concepts. This may make a system with better conceptual integrity, but it would involve a massive delay for the implementation team while the new specifications were being created. It seems to me that it is less risky for a project to begin with code and write a specification as it proceeds, instead of writing a specification that may turn out to be incorrect.