How do I apply to be a client?

Submit an application, once the application is announced for a semester. (Email me to be notified when the application is announced.)

I will evaluate applications, and if there are fixable issues, I will work with you to resolve them. If your project looks suitable for the course, you will be invited to pitch your project to the class early in the semester. Students submit project preferences and are matched with projects, and if you get a team, you work with them as a client during the semester.

What kinds of projects are a good fit?

Generally speaking, most COMP 523 projects:

• are interactive, responding to the actions of a user;
• have a graphical user interface rather than a text-based one;
• involve information stored outside of the device running the software;
• involve network requests to retrieve and store that information;
• are either a web app (meaning an app you access with your web browser, without installing software, like Gmail) or a mobile app (either iOS, Android, or cross-platform); and
• are not vitally important to the client, but more like “back burner” or side projects.

However, none of these attributes is required.

What kinds of projects are not a good fit?

• Projects that are essential to the survival of a company, or which would otherwise place undue pressure on the students.
• Static web sites, which are too simple.
• Projects requiring extensive knowledge in some domain (although in some cases you may be the subject matter expert and provide developers the minimal knowledge they need).

Do I have any restrictions on how I use the software that the students create?

Technically, work that undergraduate students complete as part of a class is their own. However, students have a clear understanding that they are building software for people who need it, and we’ve never had a greedy student who refuses to provide the source code and associated materials to the client.

I encourage students to apply a liberal open-source license (e.g. the MIT or BSD license) to their work, which enables you as a client to take the work, extend it, and even profit from it.

Projects are rarely innovative enough to develop novel intellectual property. If an IP agreement is absolutely required for your involvement—and if we don’t have enough other clients—we can accommodate you, but note that some students will not want to work on a project with this characteristic, so your chances of getting a team are smaller.

I have a confidential data set. Can I get everybody to sign an NDA?

This is an unpleasant complication. Some students may be willing to sign an NDA, but faculty and mentors are not allowed to sign one. Moreover, whether students are willing to sign an NDA then becomes another factor on a team-to-project matchmaking process that is already quite complex. Frankly, I am motivated to work to find clients that do not have these complications.

Instead, I strongly recommend creating a anonymized or sanitized version of the data set that can be shared freely.

My app deals with HIPAA- or FERPA-protected data. Is that a problem?

Yes. Students will not have the training necessary to deal with confidential information, nor can they afford to take the time to learn.

Do projects cost anything?

There is no fee for participating in the class, so this is an unusual opportunity to get software developed “for free”. However, two caveats apply:

How much can teams get done in a semester?

It can vary quite a bit based on the students’ skills at programming and collaborating, but in general, most teams can finish a basic version of a web or mobile app by the end of the semester. Typically, teams struggle to actually publish an app in an app store, partially because much of that work needs to be done by clients, and by the time everybody starts thinking about that, it’s too late. Note that the app will almost certainly not have all the functionality you hoped for. However, you are welcome to apply to be a client again the following semester to add some more features to your app.

How often should I meet with my team?

I recommend meeting biweekly for an hour, with an emphasis on reviewing the work so far—not as a manager trying to drive progress, but as a humble recipient of a free service, merely to provide feedback on whether what you see effectively captures what you want. Meeting more often is usually a challenge for the team, not just in terms of more time spent in meetings (and therefore not developing the software), but also because it can be stressful to have to prepare a demo every week. Less often can also be a challenge because:

• you have fewer total opportunities to provide feedback and home in on an app that meets your needs;
• the work you’re giving feedback about is staler, so not as fresh on the students’ minds, which means they might not remember some of the important reasons why they did things the way they did; and
• students may have built more things on top of something you want to change, which can waste time and energy and feel frustrating to you and them.

I also recommend telling your team that they should ask you clarifying questions about what you want as things come up, and do your best to reply to any questions promptly. This kind of outlet can greatly help reduce wasted effort and keep the team on track with their progress.

Do you have any advice to help me get working software by the end of the semester?

Yep! First, read the previous question and answer.

Second, try to identify the smallest set of features that could constitute an app that is useful. Be ruthless about moving things to the “do later” category. Then clearly communicate to your team about what the essentials are. This helps you and the team focus on getting something working. Once those features are done, you can start to add more, starting with the most valuable next feature. Having the essentials done is an important milestone that tends to give an extra bit of excitement to the project.

Third, don’t pressure the team to get more done or to get things done faster. That’s not your job, and you can trust the mentors and the course structure to drive progress. If you push too much, you and the team will probably get stressed and frustrated, and we might not invite you back after the semester is over.

Fourth, understand that you have some amount of control over your time preference: that is, to what extent you want lower-quality things sooner or are willing to wait until later for higher-quality things. Sometimes trying to cram in that last feature or three before the deadline means that the code is in a rather fragile state, perhaps with more bugs or insufficient tests. Building the next feature on top of that might require spending significantly more time cleaning up the mess than it would have taken to do it well the first time. For this reason, it can be wise to encourage teams to spend the last couple of weeks just cleaning house and organizing the code so that it will be easier for the next developers to understand and extend it. You get fewer features now, but it’s easier to add more features later.

Finally, appreciate your team. Thank them often for all their efforts. Maybe bring donuts to your meetings. Besides it just being considerate, it also helps establish a friendlier and more collaborative atmosphere. And you never know, maybe one of the students might be willing to stick around after the semester is over and fix the odd bug or two.

What happens to projects after the course is over?

Students are done with the course. Although they often fondly remember the experience for the rest of their lives—and indeed, many alumni report that it was their favorite course—they are never expected to do any work on the project after the semester is over.

Do you have any advice for the pitch?

Yes. I recommend motivating the problem in human terms first by talking about who is experiencing pain and how the proposed software will help. Then discuss what form you’re envisioning the software would take. You might benefit from reviewing the questions in the initial client application, as well as your answers, which were emailed to you when you applied.

Remember that you have a short time, maybe 6 minutes, to connect to significance and get students excited about your project, so make your words count. Personally, I tend to have the best results when I rehearse a talk like this as many as 10 or 15 times until it’s polished and smooth (seriously). You can leave time for questions if you want, but know that, in most pitches I’ve observed, there weren’t any.

Here are some things that students might be asking themselves about your project:

• Do I (or can I) care about this problem or the people who would benefit?
• Does this client seem like somebody I would enjoy working with, and who wouldn’t get frustrated if things aren’t going as well as they hoped?
• Does this client seem flexible and open to input about what works well at the technical level (and what doesn’t)?
• Will I be able to use my favorite programming language or tool?
• Will I get to learn about a new programming language or tool, especially one that might look good on my résumé?
• Does the project seem overwhelming in size and scope? Does the client understand that they probably won’t get everything they’re hoping for done this semester?
• Is there anything intimidating about this project? Maybe a technology or piece of hardware that I know nothing about and that sounds hard to learn?

What if I have another question, not answered here?