WorldBand Proposal: Round 2!

Hi guys, I have taken the feedback that I received from my proposal for WorldBand, and updated my proposal, which can be found here.

Please, feel free to comment or review! Thanks for your input! Special thanks to Kishore and James for reviewing my proposal version 1.

Software Design Patterns: How useful are they?

Hi there, I'm here tonight discussing the article on wikipedia for Software Design Patterns, that article can be located here.

A software design pattern is basically something you can design or draw out as a template for a piece of software that you are currently developing. This template cannot be followed instruction by instruction to achieve the desired result, rather it is more of a general direction to begin in, with milestones along the way. This is important because it gives some structure to the overall design of what you are doing, aiding you to not be lost when looking for the next step in the program.

I have user software design patterns before, mostly for outlining object oriented related objects. Diagrams I have done detailed how classes interacted, helper classes, and their basic designs. This is cool because when you start programming a class, you have it outlined before it's even done. This means if you have two classes interact with each other, you can program one before the other since you already know what functions the other will have that need to be interacted with. This was very important in a project where a group of us were working on a program together, and we didn't necessarily all work at the same time. Since we knew all of the basic class outlines, our programs could interact with each other quite easily, even if we weren't in constant communication.

Some criticism has come from the fact that these diagrams oversimplify things and this becomes a problem when you're actually implementing according to simplified diagrams. These problems can arise from thinking you needed extra functionality that wasn't necessary, or not foreseeing a certain problem. Though both of these things can happen, I don't think it is valid criticism. Problems will always arise when programming something complicated, and I think it's very useful to have an overarching structure to the program before you delve into the nitty gritty.

So, overall, I think software design patterns are awesome. I think they are useful and you will almost always be very happen you decided to make them before you get into the full body of code.

My ideal project team

Here I am today, once again talking about the project proposal I have put fort, WorldBand. You can read that proposal here.

If I were to describe the perfect team for this project in three words, those words would be:

Knowledgeable, communicative, and inspired.

Knowledgeable because the work that I'm looking to do is going to be quite complicated. They don't necessarily need to know everything before the project starts, but they need to be able to learn fast and teach others.

Communicative because the whole team needs to work together to make a project work. Everyone needs to be communicating for the site to be made correctly. This does not mean that they need to be talking more than coding. Part of being communicative means knowing how to be concise and direct, making the process easier and less time consuming.

Inspired because you have to want to work on a project to work on it. Some inspiration will come from it being a requirement for the class, and therefore to graduate, but I'm hoping a lot more inspiration will come from actually wanting to complete the project to the best possible degree. With this kind of inspiration I know the team will work hard without anyone having to enforce it, they'll all enforce themselves.

Some other contenders were thorough and hard-working.

Thorough because the team should care about all aspects of the site and should not just be throwing the site together as quickly as possible. I did not choose this because if you're communicative and inspired they will definitely be thorough.

Hard-working is obvious, of course I want team members who are actually going to work on the project and not slack off. However, I didn't choose this word because if they are inspired, hopefully that will force them to be hard-working.

What it Means to Review a Proposal

How is it that someone can read a 15 page proposal, and summarily score it in less than a page? A few concise sentences is all that it deserves? Well, maybe not, but it is pointless to restate the entire proposal in a proposal review. In fact, though it may seem harsh when there is less content in the review, this often is a good thing (for your proposal, at least) because it means there wasn't as much to talk about. If you have a solid project, then there just isn't as much to talk about. This cuts the other way too, though. If you have a truly horrible project, then there won't be much to talk about either, even if there is plenty to rant about. You usually know when a project is truly horrible though, so if you don't think this about your project chances are nobody else does either. This also doesn't mean, though, if there is a lot to talk about, your project isn't good. Sometimes, there are great projects that could almost be perfect with a few changes, and then the reviewer might just be enthusiastic to talk about these changes and why they need to happen. Sometimes, this will mean extra criticism or extended thoughts, but that does not necessarily show a decreased amount of interest in the product, sometimes it shows more.
So, in summary, the length of a review doesn't necessarily mean much. You have to look at the content of it. If the reviewer is saying this isn't going to work, then maybe you need to rethink it.. Or maybe the reviewer is just bad. But it's something you need to consider at least.

Proposal Review: Mechanapp

I'm here reviewing a proposal put forth by James Vickers, a fantastic fellow student in the cs department. You can find the proposal here.

Review of Proposal: “Mechanapp”

Proposal author: James Vickers
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create an application that can assist in the diagnosis of a car problem using probabilistic diagnosis based on other entries into the system. This will help for both professional and amateur car owners and enthusiasts to fix any problems on their own, while paying as little as possible.

Part 2: Reviewer reaction

The idea is a good one. Car repair is a mystery to a large majority of the populace and even the good ones are shooting in the dark a lot of the time. I kind of like to think of it as a “WebMD” for cars, a simple diagnosis tool so that you can get quick and easy advice.

Part 3: Quantitative scores

Format: 4

The format was good, though some information seemed to be repeated. Nothing too drastic though, and easy to look through and know the scope of each section.

Writing: 5

Very easy to read, and explains the project very well. Solid writing.

Goals and tasks: 4

The target audience was well defined, and the product was well laid out from a front end perspective. I think more analysis needs to go on on what needs to be done behind the scenes though, on the technical side.

Scope: 3

I think more thought needs to go into the platform and the technical side of the project (even if you're not sure on the platform, pick one and if your team decides to change it once you form, that's fine), but the scope of the marketing and attracting customers is good.

Plausibility: 5

Everything talked about could easily be done and is being done for different applications already.

Novelty: 4

Similar to other diagnostic tools out there, but none that I know of for cars. Seems like a very solid and novel idea.

Stakeholder identification: 2

The stakeholders are not identified, though the target audience is outlined very well.

Support and impact: 4

This could easily make an impact on anyone who works on cars, so good job there. But how will the application be supported once the product is done, and the twelve weeks are up?

Evidence: 4

You did a good job of talking about other tools out there for mechanics, but you also could have talked about other diagnostic tools out there.

Challenges and risks: 3

Technical challenges weren't addressed. A lot of marketing and viability challenges were though, such as having customers enter previous solutions into the database, which was good, since that will be a major problem upon starting up.

Proposal Review: Backpacker

Hi there, today I will be reviewing the proposal put forth by Alan Kuntz, a very talented and intelligent individual, that can be found here.

Review of Proposal: “Backpacker”

Proposal author: Alan Kuntz
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create a mobile app that will specifically gear to a backpacker's needs. These include tracking consumables, keeping battery life low, and the possibility of sending out an emergency broadcast. This application would be a lightweight accessory for a relatively new market.

Part 2: Reviewer reaction

This idea is simple and lightweight, and exactly the kind of mobile app that will hit a niche market. Because the proposer has experience in backpacking, he clearly knows the needs that should be met when developing a mobile application geared to backpackers. The emergency broadcast alone, though not new, could be extremely helpful when applied to backpackers. I really do think that this idea has potential to change the world.

Part 3: Quantitative scores

Format: 4

The format is easy to read, though sometimes sections seemed to be repeated and it was not clear upon referencing which section I read something in. However, there were still clear sections that the writer did not write outside the bounds of.

Writing: 4

The writing is clear, and very conversational. I really like how the proposer didn't get caught up in the technical aspects of the proposal (that being said, there were some issues with this I will address later), and the whole thing gelled very well. Sometimes I felt the proposer was repeating himself, however.

Goals and tasks: 5

This section was excellent. The proposer clearly thought through his target audience, and exactly what he wanted to achieve. The different features of the application are well defined and fleshed out.

Scope: 4

The features are fleshed out very well, as mentioned previously, but one thing that bothered me was there was not a mention of what platform would be used, or how the thing would be programmed. Given, though, in the timeline there was time dedicated to discussing with the team, but I would say you should pick a platform and it can be changed later.

Plausibility: 5

Everything proposed is very doable on a mobile platform, and there are other services out there that perform similar functions.

Novelty: 3.5

On one hand, it seems like the application of this to backpacking is actually very new and I would like to applaud that. On the other, I feel like many other applications out there can do very similar things. Still, though, I think that it is different enough it can find a niche market.

Stakeholder identification: 1

The stakeholders are not identified, and this needs to be addressed.

Support and impact: 4

Great job talking about how this could impact, with the emergency broadcast system having the possibility of saving a life, there will always be impact. Not much about supporting the application was covered though.

Evidence: 5

You gave evidence of other applications, all of the functionality is clearly capable with mobile technology, and just well justified in general.

Challenges and risks: 3

Technical challenges weren't really addressed, though this could be because you did not really see them as a challenge. Still, they should at least be mentioned.

Proposal Review: A/V Synthesizer

Hello all, today I will be reviewing a proposal set forth by Trent Small, a brilliant programmer in my software engineering class. You can find his proposal here.

Review of Proposal: “A/V Synthesizer”

Proposal author: Trent Small
Reviewer: Ronald Shaw (wraith55@gmail.com)

Part 1: Proposal restatement

The proposal is to create a synthesizer that incorporates both audio and visual components, as to streamline the process of creating a visual presentation for performers.

Part 2: Reviewer reaction

This is a seemingly great idea, though admittedly I know very little about the product's market and why this is necessary. I think what's really missing here is a better explanation of what the product is and why people would buy from a non-technical standpoint. Though the proposer does talk about current problems with the industry, it's very hard for me to understand these problems because I do not know much about how these synthesizers work in the first place. I'm assuming what the proposer is saying is that this synthesizer will automatically create a visual “show” based on the music that is played, but I'm honestly not sure.

Part 3: Quantitative scores

Format: 5

Extremely clean and professional looking. Everything is separated nicely and it has a table of contents for easy reference.

Writing: 4

The writing is very good, concise and to the point. That being said, some fields could be expanded and described a bit more in-depth.

Goals and tasks: 3

Obviously a lot of work has gone into the thoughts of this project, and the reviewer has the technical aspects of the product down quite well. However, a lot of questions remain to be asked. How will people here about the product? Why will people want to buy this beyond its technical superiority?

Scope: 2

I'm confused as to what the product does and does not do, so this area should be fleshed out more.

Plausibility: 4

This seems very realistic, though some of the hardware might be difficult to get a hold of or incorporate.

Novelty: 4

I'm not very sure of the current state of the industry, but this seems like a novel and useful concept.

Stakeholder identification: 4

The stakeholders are clearly identified, although I feel like there are other stakeholders not represented, like shareholders or investors.

Support and impact: 2

The proposer could go into more detail about how this will affect the music industry, and what kind of lasting support the product will offer.

Evidence: 4

The proposer provides evidence of similar products, and he is using realistic technology, so it seems that this product is plenty realistic.

Challenges and risks: 3

A lot of the technical challenges are addressed, but the risks of investing in hardware and marketing aren't addressed.