Wikipedia: software design patterns

     First off, I find it interesting that the article quickly states that many software design patterns are object-oriented (and therefore involve explicit state), and are not very applicable to function programming paradigms.  I'd like to read more about the design paradigms that functional languages are used with.  It seems like object-oriented design is sort of at the heart of many (or most) of the design patterns listed in this article.

     I think the fact that design patterns are not directly implementable (i.e. are not software specs) is both a great strength and a weakness.  This trait means they are flexible and more abstract than actual software specs or prototype programs, but there may be some ambiguity in making an implementation of some patterns.  The implementations may vary across languages and platforms to a degree that it can be brought into question if they still reflect the design they were trying to adhere to.  But after all, I guess that previous statement is a general one about the common gap that exists between software design and implementation.

Some interesting design patterns:

Bridge: "decouple an abstraction from its implementation allowing the two to vary independently".  To me, this sounds like a description of technologies like the Java Virtual Machine (JVM). 

Iterator: "Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation".  I love design patterns like this one.  When well-made, iterators are a nice abstraction that allows you to loop through a set or list without thinking about where things are or how they are stored.

Lazy initialization: "Tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed..."  I think most of the students in this class will think of Haskell when they hear this, except in that language it's called "lazy evaluation".  Though I think it's mostly an efficiency thing, lazy initialization is also cool because it allows for some flexible data structures (such as 'infinite' lists in Haskell).

Proxy: "Provide a surrogate or placeholder for another object to control access to it".  I think this is a very common design pattern.  For instance, some large software systems have a kind of 'manager' module through which all reads and writes to a database must be handled.

Lock (parallelism): "One thread puts a 'lock' on a resource, preventing other threads from accessing or modifying it".  This functionality is often critical in multi-threaded applications to prevent screwy behavior.  The MPI library for C++ and Fortran offers many ways to 'lock' a resource for a thread.

Review of reviews

So I got two reviews on my proposal, which was posted last Monday (2/3).  I intend to make revisions based on the comments I received, but also from my own thoughts.  I think reading a couple other proposals in the last week and hearing what some other people had to say about what makes one a winner or a loser has given me a better idea of where to go with it.

Some notes from the review by Ronald Shaw:

1.) Ronald said in a couple different ways that I should pick a platform and some of the key technologies (such as programming language) in the proposal.  I think he's right and I intend to incorporate that into the next release.  I think it will go along with what we talked about in class last week, "making nothing into something".
2.) He's also right that I did not fully identify my stakeholders.  I mainly only described my customer base.  I need to also think about and include the development team, automotive dealers, mechanic shops, and potentially negative stakeholders such as AllDATA (maker of some existing automotive repair software).

Some thoughts on the review by Kevin Dilts:

1.) Kevin mentioned this project proposal reminded him of some discussions from the CS 427 (Intro to AI) class last semester.  That is about the time this idea started brewing in my mind, actually.  We did a couple (rudimentary) examples of a theoretical logic system that could diagnose a car.  Much later in the class, we discussed different types of AI expert systems, including case-based expert systems.  I think this is how the idea got into my head that a hybrid expert system (case-based and rule-based) for car repair could be something new and potent.  I was also pleasantly surprised to learn that such a system apparently does not exist at present.
2.) Kevin mentioned a potential challenge of the system not addressed by the proposal.  He said there seems to be a risk that a system applying rules for diagnosis in a probabilistic manner (based on case histories, as this project proposes to do) has some risk of giving bad diagnoses.  I do not believe this risk exists, but it illustrates that perhaps I didn't explain this part of the system very well.  Imagine the system is leading the user through a diagnostic chart as if it were a tree, using some kind of graph search algorithm like Breadth-First Search (BFS).  However, in this system, the search is directed towards the branches of the tree which are believed to be the most promising (i.e. are the most common causes of a particular problem on that vehicle or class of vehicles in the past).  So, the search is traversing the most promising branches of the search space first (we hope).  Even with the worst possible information guiding this process, the search algorithm is still complete despite its probabilistic nature (after all, it's built on top of BFS).  I intend to simplify and detail this description and add it to the proposal so it may be more easily understood.

Thoughts on the "Software craftsmanship" movement

On the face of them, the ideas associated with this "software craftsmanship" movement seem beautiful, even noble.  It basically challenges some assumptions about the making of software, namely that it is strictly a kind of methodical and predictable process.  It makes a case that software engineering is as much a craft as it is a science or engineering discipline.  I like these ideas, I think.  One thing I'm not sure about is some of the ways that they phrase them.
From the "Manifesto for Software Craftsmanship" (http://manifesto.softwarecraftsmanship.org/):

"Not only working software, but also well-crafted software"

It's kind of unclear what this means.  I think it's supposed to mean all the things we as software people like in code design, such as reusability, readability, and robustness.  But putting it this way, in my opinion, is too vague.  It leaves it open to a lot of interpretation, and might be called "soft" or "washy" by outsiders.

"Not only customer collaborations, but also productive partnerships"

I don't really get this one either.  Isn't a 'customer collaboration' a kind of productive partnership?  Do all transactions in the software world have to be in the form of some kind of partnership?  I don't see anything particularly wrong with contracted work with a company that doesn't care about your company.  This statement in the manifesto seems to suggest every company you make software for should have a personal interest in your company.  If so, is that reasonable or even desirable?

I do agree with this movement that the coding skills of the developers themselves are important, but I don't agree that they're the most important.  To claim that's the most important part of a process as complex as software engineering is to close your eyes to so much.  The best coders the world over could be led into nowhere by clueless project managers or a marketing team not bringing in paying customers.  To claim that the quality of produced code is the most important aspect of a project is somehow noble, but appears misguided.  The quality of the code really makes little difference on what a system does; it makes a bigger difference on what the system can be made to do easily (i.e. modularity).

My ideal project team member

The three qualities each member of my team will have, ideally:

1.) Reliable

This is critical.  I need someone who live by their word so I can count on them.  In a small team project like this one, the failure of one member could bring it all crashing down.  Without reliability, a person may as well be nothing at all.

2.) Adaptable

The only thing constant is change.  Ideally, the developer can quickly change his actions and thinking to cope with rapid change.  He should be able to think on their feet as conditions evolve or the worst-case scenario unfolds.

3.) Dedicated

The person has to have a strongest desire to succeed with this project.  This trait means that this person strives for excellence in everything he does, even those he dislikes or thinks he's weak at.  It also means he does not fold when things get a little dicey.

Three other qualities not in the top three, but which are also highly desirable:

4.) Creative

In the view of many, software engineering is as much an art as a science.  Often, the best solutions come from the more creative among the group.  Creativity in this context enables beautiful and novel solutions that a logical mind simply doesn't make on its own.

5.) Honest

This quality is important for the group to trust each other and communicate effectively.  If a team member feels there is a problem looming, they should say so even if it may offend another member (who, perhaps, is the cause).  An honest team member gives their true opinion, regardless of the politics of the group.

6.) Personable

This trait simply means the person is easy to get along with and can effectively communicate with others.  It almost warrants a slot in the top 3, but is not required for an awesome team member.  A likeable developer is a big plus when talking to customers or with the team.

Review of "WorldBand" proposal by Ronald Shaw

Review of proposal: "WorldBand"

Proposal author:  Ronald Shaw

(blog: http://rbshaw5.blogspot.com/

Proposal reviewer: James Vickers (jvick3@unm.edu)

Proposal restatement

         The proposal is the make a social web site for collaboration between bands.  For instance, a user could upload a track or sample from a simple instrument and other users can do the same (but likely for other instruments), by which music can be made from distinct pieces written by different people.

Reviewer reaction

         The project is novel and interesting.  I'm usually not big on social media ideas, but this one strikes me as cool on the surface.  I think much more attention needs to be paid to the music collaboration tool itself.  I think perhaps the proposal writer is withholding details on this aspect on purpose, which may or may not be wise (we need a taste of it at least).

Quantitative scores

Format:

            Good layout.  I especially like the "Context of work" diagram (section 4b), which shows basic transactions to take place in the project's ecosystem.  The in-depth timeline section is detailed, but at a cost of added length.  It could possibly be put into some kind of calendar format.  I also think the "Work partitioning table" (section 4c) could probably use a column for the actors involved (i.e. user and site, advertiser and site, etc.).

Writing: 5

            No complaints.  Style is clear and simple to read.

Goals and tasks: 3

            The goals of the web site interface are well-defined, but those of the music collaboration tool it hosts need to be expanded.  It's a lot of the novelty of the project, and we need to know how users from across the world will be able to work with each other without getting frustrated.

Scope: 5

            The project is meant to be a web site for people to upload, download (for a fee), and collaboratively create new music by combining tracks or samples.  Little ambiguity to be had.

Plausibility: 4

            The product seems plausible overall.  One possible difficulty is managing the collaboration between users on a single music file to try and prevent themselves from clobbering each other's work.

Novelty:  5

         This idea seems so good that I'm still trying to figure out if it already exists.  It's stated that GarageBand (by Apple) does not have a functionality to collaborate on music online, which I find surprising (not that I've used GarageBand, I just thought that was part of its purpose).  If such a site/tool doesn't exist, it seems like it should come into existence.

Stakeholder identification: 4

            Stakeholders are listed neatly.  I do however think some are missing, related to the possibility of plagiarized music being sold on the site.  In that case, people such as the RIAA (Recording Industry Artists of America) or government agencies could become negative stakeholders.

Support and impact:

            The project has convincing impact, in that it could be used to help people from all over the world make music together.  It's one of those ideas we only dream of in the internet age.  The more users the site has, the better it gets; this growth model is a double-edged sword by which some sites like YouTube become huge and others die in the night without a sound.

Evidence:  4

            Your budget is nice and detailed, but I notice that week 2 is budgeted well above the 75 hours you said you had available for each week.  I find that you have done your research on web design and the related technologies, as well as competitors products and the features they lack for your product to fill.  The "Context of work" (section 4b) diagram is a nice summary view of the project's scope and function.  There is room for improvement in describing the type of interface envisioned to allow collaborative music writing, the crux of the proposal.

Challenges and risks: 3

            I think there is an important legal and ethical risk missing from the proposal.  The site is paying people who create parts of music tracks when they are downloaded by users.  What isn't mentioned is the distinct possibility that some of those samples or tracks are already plagiarized.  In that case, this site will be paying the wrong people for music that neither the site nor the person who uploaded it own.  I think the other challenges and risks are addressed rigorously.

Proposal review: "RAWAR"

Review of proposal: "RAWAR: Virtual Battleground for Settling Online Disputes

Proposal author:  Cameron Smith

(blog: http://cs460se.blogspot.com/)

Proposal reviewer: James Vickers (jvick3@unm.edu)

Proposal restatement

            The proposal is to make a 3D web game where people having disputes on the internet can invite the other party to settle matters in a virtual fight.  The program also keeps a database to keep track of it's users actions.  The revenue for the project is to come from advertising and selling user data.

Reviewer reaction

            It's an interesting idea that reminds me of the show Celebrity Deathmatch, which was popular when I was a lad.  One thing I think the proposal needs to address is that some facilities to 'resolve' online disputes by fighting do exist, in that people can challenge each other to existing online multiplier games such as Call of Duty.  I understand, however, that the point of this project is to provide a game that anyone can play.  Making revenue from advertising sounds fine, but we need more info on the "selling user data" part.  Who buys the data and why?  What kind of data can we collect on participants in these games?

Quantitative scores

Format: 3

            Format is OK, but could be improved.  Would like to see charts or graphs for budget and timeline portions, as they are easier to read.

Writing: 4

            Writing style is good overall, but paper could use proofreading.  The wrong words are used in a couple places by accident.

Goals and tasks: 3

            The how-to of the invitation to the online virtual fight is well-described, but the gameplay itself could more description.  The timeline is detailed, but some lines in it are unclear, such as "develop a name for the game".  Doesn't the game already have a name ("RAWAR")?  Also, how detailed is the physics engine going to get?  Is there any idea of using an existing physics engine, if available?

Scope: 5

            This project consists of a 3D fighting game, with the special purpose of allowing people to virtually back up their trash talk with fighting. 

Plausibility: 4

            I am concerned that this game in particular needs to be super good for the whole system to work.  With the purpose of the project being a central place people come to resolve online grievances, the game needs to be good enough that no one scoffs when invited to it.  The short time frame to make the game is acknowledged in the proposal, but it is not discussed how much time or money this project will require to fully complete.  Will the game be a fully-featured competitor to state-of-the-art fighting games, or will it be simple in comparison?  However, time and money aside, making a game of this sort is totally possible.

Novelty:  4

            While I've never heard of a game whose explicit purpose is for people to meet and fight over things said on the internet, there are some facilities to do this already, such as online multiplayer gaming.  That is not to say there isn't room for a game geared specifically to this purpose.

Stakeholder identification: 1

            From reading the proposal, I'm inclined the believe this game is intended for everyone on the internet.  However, I would think this game is more likely to succeed with say, 18-year-olds than 40-year-olds.  It would also be helpful to hear more about advertisers who might buy space on the site (i.e. energy drinks) and what kinds of companies would be interested in purchasing user information.  Is there any notion of this product's interaction with existing social media (as this is somewhat related)?  Is there concern about checking the age of users (and how much of a farce this tends to be) if the game is to be particularly violent?

Support and impact: 2

            One question that the proposal needs to address is what kind of companies would advertise on the site, which is the main source of revenue claimed.  What's the target audience of the game?  Age?  Income?  Education level?  This questions must be answered for potential advertisers.  It is also not clear how much time and money the project will require to reach a mature enough state to draw advertising revenue for continued development and/or profit.

Evidence:  3

            Proposal cites existing technologies on which the game can be built.  A detailed user story is given.  The motivation of building this game and the issue it solves (lack of resolution to grievances between people online) is clearly described and makes basic sense.  The writer shows knowledge of the principles of game design and graphics.  However, the proposal needs more details on the budget in order to convince people it's not going to bankrupt them.  Some things are listed in the budget without the estimated costs associated with them.  This is scary to an investor!

Challenges and risks: 4

            The proposal acknowledges that game development of this magnitude will be non-trivial.  The planned used of WebGL is stated as a risk because of it's recent construction and lack of long-standing use.  A challenge which I feel exists, but is not listed in the proposal, is that the project could lose support before it can get to a revenue-generating state.  This goes along with the statement that developing a good game will cost high in time and therefore money.  It is a large risk on this project because the advertising revenue expected is dependent on high traffic to the site, something that will fall through if the game does not mature fast enough.

Full software proposal

The full version of the proposal can be found at:

cs.unm.edu/~jvick3/full_proposal.pdf