Gregory M. Kapfhammer

Associate Professor of Computer Science

http://www.cs.allegheny.edu/~gkapfham/

  
View  Edit  Uploads  History  Top  Changes  Search

Chrysler Goes to "Extremes"




  1. The authors of this article state that the always attempted to leave their system in the simplest state possible. In order to do this, they never designed the system to be more general than currently needed. What do you think of this principle? Are there any pitfalls that might be associated with doing the simplest thing that works? 

instanceof

I don't have a tangible example at the moment but the immediate problem that comes to mind with doing "the simplest thing that works" is ethics. This solution is rather pragmatic. The simplest thing is not always the moral thing to do - again I don't know how this applies to CS and SE, but I'm sure that it does.

A focus on "what works", on the the hard and fast facts with little theory could leave other areas lacking. Performance for example - Bubble sort is one of the simplest ways to sort, but heap sort is much more efficient. I'm sure the people at Chrysler are experienced enough to know to not to use bubble sort but I'm also sure that there are higher-level issues in design/coding that are comparable.

Dan Fiedler

Do you think that it is ethical to over-engineer the software that you provide to a customer? For example, suppose that your customer needs you to develop a software system that requires the traversal of simple tree-like structures. Is it ethical to spend their money to implement a solution that uses the Visitor design pattern if a simple block of conditional logic with
will solve the problem? Can you do the simplest thing that works and not leave the system in a high-quality state? Why did you think that YAGNI would result in low-quality code that would be un-ethical to ship? Greg

I agree with doing the simplest thing that works. I think that they are correct in the fact that it keeps the programmer from adding unnecessary code. This simplicity also helps to make the code "lean and mean," adding to easier readability. This helps future programmers to make changes and upgrades easily. I also agree with the C3 team in the fact that they do not worry about the future, and deliver the product that their customer wants now.

I think one main pitfall would be to have too much simplicity and not get the job done. Also the programmer might not plan out the code effectively or leave out too much code out trying to be too simple. These are two other factors that could work against the end product.
Joe Zumpella

What is problematic about leaving out code that does not solve part of the problem at hand? Did you interpret the need to simplicity in a manner that would allow for the creation of code that does not solve the desired problem? Personally, I felt that the code must solve the desired problem in the simplest fashion possible. Agile software development (or, any other methodology, for that matter) cannot solve part of a problem in software! While will a drive towards simplicity create badly planned code? Greg

The key part of that statement is "that works". they're not going to do the simplest thing and then hope that it fufills all the design goals for the project. They are going to do the simplest thing that gets the job done. If that happends to be bubble sort then it'll get used. But if part of the specification says that the sort has to be fast then they'll use a different method.

The one potential problem that I can see with this method is that potentially you put out inferior software. Just because it works doesn't have to mean that it works well. In the design process the developers may propose certain short cuts or lower quality standards that the client may want but not know they want. This design process forces the clients to place a lot of trust on the developers on how hight the quality of the software must be to be usable.
Jim Clause

Good points! I think that you are on the right track. What does it works really mean? If we have a non-functional requirement that makes some performance requirements for our system, shouldn't "it works" handle this requirement? How is it possible for simplicity to result in low quality code? If the code is simple and passes all of its tests, why would you feel that you were sacrificing quality? Greg

  • The authors assert that it is important to establish a coding standard to ensure that all developers can read the code written by other developers. Do you agree with this assertion? Suppose that you were asked to develop a coding standard for the Java programming laguage; what would your standard look like? (You might try to look for existing standards and base yours off of these).



I do agree with this assertion. I don't know how many times I've tried to help (or have had someone try to help me) a classmate and I have no idea how to begin looking at their code. And we're experiencing these problems on small labs where our programs have under 500 lines of code. I can't imagine attempting this where there's more than 5000 lines of code.

Javadoc's commenting style is a good beginning for code standards. I would also add the "normal" practices for Java that I've learned in my classes here - finals all caps, indents, descriptive variable and method names... I also think having everyone program in the same environment helps a great deal as well, such as in emacs where everything is color coded nicely and indented correctly. It could only get better with a more powerful environment.
Dan Fiedler

I do agree with this statement. Readability is a very important factor for programmers to remember. Without it no one would ever be able to upgrade code or go in and make necessary changes to fix bugs. If that is not possible then the code becomes worthless.

I think that commenting is the most important part of having readable code. The Javadoc commenting style makes it very easy. I'm sure there are other commenting styles out there that are just as good but I would make sure that everyone uses the same style. I think other obvious standards would be to uses the same programming environment and use all normal programming techniques. I think another standard that goes along with simplistic programming would be to keep code in nice short methods using good design patterns and not having long main methods. This also adds to easy understanding of the code.
Joe Zumpella

JavaDoc isn't really a coding style. It is just one way to genereate documentation for a program. It doesn't specify anything about how the actual code of the program should look. Just because you know what a section fo code does doesn't mean that you know how it does it or understand how the change the code. A coding standard is something more like what is specified here: http://gee.cs.oswego.edu/dl/html/javaCodingStd.html It describes naving conventions for variables and functions guidlines for function placement and how to arrange the files in the project using packages and directory structures.

While a standard for coding style would be useful in promting reusablility and maitainability. It also makes developers more interchangeable. So if you want to have job security it's probably better to write code that only you can understand and update.
Jim Clause

Again, I have to agree with Jim. Just because you use JavaDoc does not mean that you are following a coding style. However, the usage of JavaDoc might be one part of a code style. Jim also alluding to another tenet of XP: it should be possible for you to read the code written by your team members and not be able to tell who wrote that code! Yes, this might be somewhat detrimental in terms of job security, but I think that it is particularly useful for a software development team! (We will strive in this direction when we conduct the long-term software development assignment). Greg

  • The C3 Team only released source code when all of their unit tests passed at 100%. Do you think that this is an effective mechanism for measuring the quality of a software system? What measures for software quality would you propose to augment their measure?


Having all unit tests passing at 100% is a good beginning but is not enough; there needs to be integration testing as well. Testing the entire system (as difficult as that may be) is needed after having every unit tested.

I think that Chrysler did do intergration testing though - they said they had "over 3000 unit tests" and that their "customers own over six hundred functional tests, which are the final certification of the system."

Complete unit testing and partial integration testing is a very good mechanism for measuring the quality of the software system. The only measure I could propose to augment this would be attempting to break the software system, make it run on different platforms (even platforms its not supposed to be run on) or perhaps what's been briefly mentioned in class, fault injection. I'm sure we'll learn about other ways they could augment their testing, but I don't know of any yet.
Dan Fiedler

I think that unit testing is the first testing step that needs to be taken. This way if something does fail you know exactly where the error originates it becomes very easy to fix. I think this is a very important step.

If all units pass, as did Chrysler's, then you begin to test the units as a whole. This only makes sense since each unit could work but when put together, they fail. Now the method of testing is what makes a difference. My understanding is that Chrysler uses their customers to actually test the final product. I think this can be a good thing because the programmers really understand what is wanted by the customer and they can provide the correct code for the final product. I think that it is crucial to keep focused on the final product and what is actually wanted by the customer. I think that the testing should evolve around testing what the customer wants.

The unit testing usually tests the code which is important, but then more tests must ensure that the final product actually solves the problem at hand.
Joe Zumpella

I think that if they were really concerned with creating thier product in the shortest amount of time possible they should release the code before it tests out 100% on their tests. I think that the best way to find problems in the software is it use it. The people that use the software everyday have a set routine that they do. If you release software to them you'll be use that the software meets thier specifications and if there are bugs you can concentrate on the more serious ones first. Then after you have taken care of the all the problems in the daily routine of the users then yo can start running other integration tests and unit tests to test functionality that users are corrently not getting to. Although if they are really serious about doing the bare minimum there shouldn't be a whole lot else that the users won't get to because they system was designed to just meet minimum requirements.

Jim Clause

So, you are not advocating that we abandon unit testing, but rather that we ship code even if it has defects inside of it? How will usage in the real-world help us to better learn about these defects?
Or, are you advocating that we test less and then allow our users to find the defects in our software? Dan, you initially commented about software and ethics in the first question: what do you think about this assertion? Greg

Again, I think that it is important to realize that the statement "our tests passed at 100%" might not tell us that much. Personally, I think that we need to consider the issue of test adequacy so that we can measure the quality of our test cases. If we do not adequately test the system with out unit tests, then 100% pass-rate might not shed that much insight into the quality of the system! What are the main adequacy measures that we have discussed in class (we will delve into them in detail later on in the semester!) Greg


Link to this Page