Slashdot Mirror
Teaching Programming to Non-Developers
Eric asks: "I'm teaching a web application development class at a local public university. The students are seniors in the business program; the course is intended to expose them to development practice (we're using PHP and MySQL) but is not intended to turn them into developers. So what would the Slashdot community recommend within the curriculum? How would you teach web development to the managers of the future, and why?"
Then the day before the assignment is due, totally change the requirements and expectations from them.
Then knock their grade down for not completing the assignment on time.
Maybe that will give them some insight to what they do to programmers when they make decisions like "Oh, this one little functionality change won't make a difference to the IT team. I'll go ahead and promise the customer it will be changed by tomorrow."
You don't have time. Plus, if they wind up being managers, they don't need to know about PHP and MySQL's specifics. You're only going to have about enough time to teach them how to make a completely watered-down application, which will be totally useless to them, and won't help them understand what real developers are doing.
Instead, show them what the LAMP model is all about. Bring up issues like:
- LAMP vs. Oracle
- Open vs. Proprietary
- MySQL vs. PostgreSQL
- read-heavy applications vs. transaction-heavy applications
- Dealing with high demand (/. effect). You might want to mention:
- Smart caching with Squid/mod_proxy
- Database optimization
- Making non-dynamic pages static
- Using a smaller http server to serve static content (such as thttpd or a barebones Apache)
- Moving from PHP to mod_perl for high-traffic applications
- One big server vs. two or three (or more) very cheap servers
- Time vs. Money:
- In-house vs. Outside development
- Creating a new system vs. Adapting existing system (which may cost)
- etc
Try to get some opinions and discussions happening -- these high-level topics are more useful to them than how to set up an over-simplified database-driven website that won't scale.-ben
I have had _way_ too many bosses, at all levels of the chain of command who thought they knew how to build software. One was the president of the government systems division, who thought he was a software guy because he had hung tapes for a mainframe when he was in the air force 30 years before. Lots of EEs think they know software because they wrote one-off programs to solve homework assignments. I once ran into a PhD (5 degrees actually) who was leaving the academy to run a 400 person project. Biggest thing he had ever done, 5 people for 2 semesters.
If one of these b-students ever gets to be a boss of mine, and acts like they know anything about the industrial software process, I'm going to find you.
And hurt you.
Here is a very realistic way to teach this class.
Assume the class is 10 weeks
Week 1: Design a web page that pulls data from the database and formats it. By the end of the week it not only needs to work, but you should have documented the time it took to do each task and make sure you comment your code.
Week 2: Add a new feature. Make this feature vague. Again be sure to document your code and keep track of your time.
Week 3: Act upset that no one got the feature right. Add a new feature, fix the old feature, and have everyone trade ownership of the code. Hence everyone is now working on code they did not write. (I hope everyone did a good job at documeting their code) Be sure to also keep track of your time.
Week 4: Now present a Gantt Chart of schedules based on everyone's tracking of time. Now add another new feature, did everyone fix the old feature? Trade code again, be sure to keep track of your time, document code and make sure you hit your milestones as per the Gannt chart or this will affect your grade.
Week 5: Now that everyone is pissed off. Ask the class what they have learned in business classes that could make this process better? Then take that information and what you hope to teach about good documentation and design and start all over again. This time I am sure everyone will be listening.
Week 6-10: Still trade code, document, and keep schedules. But this time I think everyone will see the wisdom in what you are teaching.
The point it seems everyone is making is don't so much teach them how to code, as much as show them how to manage someone who codes by placing them in the programmer's position.