Thoughts on Wikipedia info on 'Agile software development'

   First of all, the claims of what Agile is are just plain appealing on the surface.  The article begins by saying that Agile "encourages rapid and flexible response to change" and "promotes foreseen tight interactions throughout the development cycle".  Sounds good, right?  It is often stated (sometimes without evidence, as some kind of anecdote) that many software projects are never fully completed because by the time they are some ways along in construction, one of two basic things happens.  Either the project falls out of scope with what the customer originally wanted (drifted, in a sense), or the product has become unnecessary or unfeasible in some way (too expensive, obsolete, whatever).  It would appear that one of the stated methodologies of Agile is aimed at addressing this issue (to the extent that it exists) by promoting close interaction between developers, managers, and the client.

     I'll say it was surprising to learn that the famed "Agile Manifesto" is so short.  The actual content of it is a mere 68 words.  However, you can see responses to some of the known issues with software development I just mentioned.  For instance, the Manifesto says it values "responding to change over following a plan".  To me, this means that Agile is expressly concerned with the pitfall of blindly 'completing' a project as planned despite changing conditions being present.  In a similar sense, the other three statements of value indicate a belief that interactions are more valuable than documents and working software is better than descriptions of it.  This all seems to make basic sense, given some canonical miscommunications between clients and the developers they contract with.

     Another interesting note in this article is the idea of a continuum of software development methods between ones that are 'adaptive' or 'predictive'.  Agile is stated to be an adaptive method, in that it allows for changing requirements and can be quite uncertain about the future tasks and problems the current project will present.  This is in contrast to a predictive method, which generally attempts to map out or 'predict' the issues and milestones of a project in advance and not change them unless absolutely necessary.  The notion of a predictive method almost seems flawed to me, as it is rigid in a way that does not allow it to actually do useful things unless it can know exactly what they will be far in advance.

Preliminary project timeline

The project timeline is available in both Excel format (xlsx) and as a JPEG at:

cs.unm.edu/~jvick3

I simply found this to be the easiest way to post these documents.

Software proposal

            For professional automotive mechanics as well as those who like to tinker for themselves, the main information tool in use is that plain old shop manual.  There are some software products that provide convenient access to this style of information, with a format generally the same as the book.  However, these shop manuals are focused on the how-to of specific repairs; they have little or no information on how to diagnose problems in the first place.  The products that do currently exist for this purpose are directed towards reading and displaying engine management information ("trouble codes").  This is a very useful function, especially with the increasing complexity and abilities of such automotive systems, but unfortunately a blind eye is turned to problems that are not detected by existing sensors.  These "code reader" diagnostic tools only work for problems the car's computer system is aware of, and are useless on many of the systems on the car (think brakes, axles, suspension, fluids, etc.).  Code readers also only work on relatively new vehicles, made in 1996 and up.

            This software package will help both professional and hobbyist mechanics alike in two key ways.  One, it will provide interactive diagnostic procedures for the mechanic to follow.  This will help the person stay on track, ensure the steps are followed correctly, and make the process less confusing.  Mistakes are often made while using the standard flavor of diagnostic charts, as enacting the steps makes the mechanic have to go try something.  When they return, they often forget which step they were on, the ones they have tried, and experimental results.  Second, the user will have the option to report the solution to their problem and contribute it to a centralized knowledge base.  It often appears that seasoned mechanics are able to diagnose difficult issues more easily because of their (frequently vague) experience with various problems on various cars.  This centralized knowledge base will provide a way for the less experienced to leverage the same kind of case-based reasoning to use the results of previous events. 

            The diagnostic procedure assistance side of the program will be comprised of graph search methods on existing diagnostic trees.  The centralized knowledge base will be implemented as a web database that can be queried directly from the application.  This software must be easy-to-use and intuitive to get professional mechanics to actually like it, and also cannot be intimidating to a less-skilled hobbyist.

            This software is intended for use on personal computers (Windows/Mac/Linux) and as a mobile app.  The mobile platform is crucial because of the need to have the software readily available for use where the vehicle is.  The tool will cost money to purchase (non-recurring), and the use of the centralized knowledge base is included for free.  The knowledge base should be free as to encourage users to participate as much as possible, increasing it's usefulness.  Existing automotive software usually charge a recurring fee for service; for example, the AllDATA service costs $27 per year or 5 years for $45, covering one specific vehicle.  This product will not provide enough vehicle-specific details (which must be updated as changes occur on newer models) to justify that type of pricing model.

            

Response to Wikipedia on Software Engineering

     Let's start with the formal definition of software engineering.  I would say the one that begins this article is the most accurate: ". . . the study and application of engineering to the design, development, and maintenance of software".  I think that this definition, unlike some of the alternate ones following it, covers the whole field without being too narrow.  One of these definitions states that the field exists to ". . . economically obtain software", which is basically true, but sort of omits the critical area of software maintenance.  Another of the definitions calls it an 'engineering discipline'; as we'll talk about later, this description is not without contention.  One of the informal definitions given by the article is especially interesting to me.  It states that software engineering is a broad term relating to the practice of programming computers, as opposed to computer science, which pertains to the theory of programming computers.  As evidenced by the myriad courses everyone in this class has taken which have little or no programming in them, that synopsis of computer science seems inaccurate at best.  The analogy I always think of is that saying computer science is about programming is akin to saying math is about arithmetic.  Despite that, I would wager that many among us (myself included) have given a similar answer when asked to explain what we are going to school for.  That description at least gets most of the point across, and prevents the listener from thinking we are learning to fix computers (physically) or provide over-the-phone tech support.

     Some of the notions around on how to measure the complexity of software are, to me at least, laughable.  This article has a formula listed in it, called the "Construction Cost Model", to estimate the number of man-years required to make a piece of software having a certain number of lines of code (SLOC, or Software Lines Of Code).  The very definition of a "line of code" is itself ambiguous and doesn't consider the varying expressiveness of programming languages (think x86 assembly vs. Haskell).  Recently, I was tasked with estimating the size and complexity of a large piece of open-source software at my job.  There are various software tools that do such a task, and their results can vary enormously.  When I used a few different tools on the same source code repository, I got answers that varied by hundred of thousands of lines of code (something like ~25-50% of the approximate code base).  These differences are the result of a lack of established metrics on what should be included in the count; for example, does a line of C++ with only a closing bracket ('{' or '}') count as a line of code?  The Wikipedia article later counters this practice by saying "This [counting SLOC] is like describing and measuring a complicated piece of machinery in kilograms only".  I couldn't agree with that statement more.  Furthermore, measuring the number of lines of code does not account for myriad other factors relating to the development speed and quality of code.  These factors include development tool quality and utilization, physical development environment (i.e. loud and cooperative vs. quiet and isolated), novelty of the problem(s) to be solved, and more.  The claim made by some (including the man with the man-years formula, Barry W. Boehm) that the main factor in software development is the skill of the developers themselves woefully underestimates the number of factors present in the process.

     A short word with my take on licensing and certification for software engineers.  Namely, why I think it has proved more difficult than expected to nail down and define.  First, it's the fact that the field is so new; it has only been around for around 70 solid years, and for most people, much less.  It has grown and changed tremendously during that time and continues to.  Second, it can be argued that some aspects of software development are less of an engineering discipline and more of an art.  After all, authoring good software is in some way like writing a book.  Sure, there are basic guidelines that most everyone should follow (like grammar and layout), but what makes a 'good' book is hard to define and analyze at present.  I believe the same is often true for software.  This essay by Paul Graham describes this idea pretty well, but don't feel obligated to read the whole thing:

http://www.paulgraham.com/hp.html

   In closing, I would like to mention something I strongly believe in, but that was only briefly stated in the article.  Under "Software Development Process", it says, "the software engineering market is being gradually shifted towards component based".  I really think that modular design (individual components that can be connected together in flexible ways) is the only future for powerful and reliable software in this world.  I think we have all had experience with writing code that we are just sure has already been written by others in this same programming language, probably a hundred times.  We, as an industry, do not seem to reuse our work nearly as much as we could.  Modular design will hopefully do for software what similar principles did for manufacturing and mechanical systems.  Before the days of Henry Ford, Eli Whitney, and Samuel Colt, many machines were built custom rather than by integrating standardized parts.  This made repairs difficult and different for each machine.  I think this design principle is critical, and applies to software just as much as to cotton gins and revolvers.