Advice on Individual Projects

I often get requests, mostly from undergraduates, who are developing an independent software-related project and would like advice or advising.

I generally cannot offer 1-on-1 advising for independent projects that aren’t part of my research, teaching, and service commitments. However, many students have found the following general advice to be helpful.

Do you have knowledge of software engineering practices? Building a prototype for learning purposes or for a hackathon is very different from building something that will have a future and that other people will actually depend on. CS169A teaches the basic foundations of software engineering (which is quite distinct from programming) and CS169L puts those skills to use in team projects building or enhancing software pro bono for a nonprofit, NGO, or campus unit. Without some basic skills, it will be difficult to get beyond the prototype stage. If you’re not in a position to take these courses at Cal, most of the material of CS169A is available through noncredit courses on edX and the textbook can be downloaded free or purchased as hardcopy or Kindle on Amazon.

Are you confident the problem you’re trying to solve is one for which people would actually pay for a solution? If you’re building a product or service for others to use (as opposed to something you yourself need), have you talked in detail and face-to-face with your potential customers? Are you sure that what you are planning to build is something they actually would want and would be willing to pay for? Software people are techno-apologists—very often, something that we think would be cool turns out to have little value to the actual customers who would have to pay for it. A lot of what’s in CS169A is about how to make sure you are building the right thing (as well as building the thing right—that’s testing).

Beware of the ease of partial success. The double-edged sword of software development is that it’s pretty easy to get something that looks like it partially works. Sometimes, the path from that to a usable product is a just a lot of disciplined work. Other times, and not infrequently, the design underlying the prototype is simply unsuitable for “growing” into a real product, and the only path forward is to learn from the prototype, throw it away, and start over. Again, CS169A covers how to approach such situations.

Can you get the customer involved early? The earlier you can show a working prototype to a customer, the earlier you’ll know if you’re on the right track and if it’s worth going farther. Of course, if you’re building the project as a way to learn some skill, this doesn’t matter. But if you have aspirations to solve someone else’s problem, it is distressingly easy to fool yourself into thinking you are doing so because you haven’t been in the shoes of the customer whose problem you think you’re solving. There is no such thing as too early or too often when it comes to validating your idea, unless you yourself are the intended customer and know exactly what you want.

I do wish I had time to advise on independent projects, and if you are working on a specific project and have a specific question about technology stacks, software practice, etc., I will do my best to provide some targeted advice. The best thing to do is email me with a statement of your question that is as specific as possible and we’ll see how best to proceed.