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?"

Comments

Requirements

[bill_mcgonigle]

How would you teach web development to the managers of the future, and why?

Set it up so that they're building an app for you. Let them just go at it. Have them draw up the specs and implement it. Then change the requirements on them at the last minute and bitch and moan at them about their product.

No, seriously - tough love 'em. It'll give them an appreciation as to how things ought to be done and why. You can tell them all about the need for good requirements in a lecture but it's going to go in one ear and out the other until it actually bites them. If you're feeling generous, do this halfway through so they get a chance to fix it.

These guys are going to be managers so you're doing them a favor - if they learn this lesson when their project/budget is on the line it's already too late (Peter Principle aside).

My best Software Engineering class involved a project to build a full groupware calendar. 4 CS students, 5 weeks. The prof acted shocked that just implementing something the scope of Groupwise or Exchange was too much to bite off for the group/time but in retrospect he knew full well what he was doing and was trying to teach us some lessons about what/where to cut and shipping on a schedule. Figures he was a visiting professor - the resident algorithms guys hated him.

Re:Have them write a program...

[maeglin]

It's a good joke, but I think it's also a good idea.

My original reaction to this was "Good God! Don't teach them anything!!!" Nothing is more frustrating than when you've got some VP of something-or-other screaming: "What do you mean it takes more than two weeks to develop an online financial service center!!!" Followed by, "I could do it in 2 days in ASP!!!"

Or worse, someone up your own chain of command cobbling something together in the middle of the night and saying, "Here, I got the hard part done. Just fill in the details" as he passes over the biggest pile of spaghetti code ever devised.

In a small course you're never going to be able to get them to understand the true value of good design methodology, so perhaps an understanding of unreasonable expectations would suffice as an alternative.

Programming for Managers 101

[Glonoinha]

Step 1. Get out checkbook.
Step 2. Hire decent developers
Step 3. Make the business requirements clear, valid, non-conflicting, and technically viable
Step 4. Give the developers a good development environment (hardware, software, and surroundings)
Step 5. Run interference, keep the end users from hassling your developers
Step 6. ???
Step 7. Profit!

Teach them to think first

[macemoneta]

Spend a day teaching them to itemize, in excrutiating detail, a sequence of events like "waking up and getting ready for work". Part of the problem facing people first learning to program is learning to think at a detail level.

This also lets you highlight that the sequence of events is important too. Getting dressed before getting in the shower is nonsensical, and that puts sequential operations in perspective.

I tutored computer programming in college, and had some folks bring in their assignments. The code looked like it had been copied/pasted (manually, this was the late '70s) in random order. Close file; read file; open file; process file. They couldn't understand that the sequence of instructions made a difference.

Teach the basics first!

[Anonymous Coward]

1) Teach them to learn the local employment laws so they know how many weeks they have to work to be eligible for unemployment benefits (only works in civilized countries)

2) Teach them how the local unemployment system works, do they need to call in, fill in a card, what?

3) Teach them about the cult, err universities, that will suck the money right out of their pockets with a vacuum cleaner, in exchange for reading 150$ textbooks with a disgruntled professor.

4) Teach them that about 90% of what they paid to learn in the cult will be a) useless, b) forgotten in two years as all you can get are entry-level jobs so when you *do* get a good job, you have to learn over again at your own expense anyways.

5) Teach them that working in a field that involves cheap commodities like computers and software and is saturated with cults and people, will mean they have to compete every day for the rest of their lives to fight for crumbs.

6) Teach them to interpret HR "requirements" like "5 years experience for 1 year old software": it means HR lives on Mercury, where the year is 88 Earth days.

7) Teach them how to make a CV that's full of lies that can't be contradicted (because everyone else does, because of #6 and #5).

8) Teach them how to suck up in interviews, and how to handle the pseudo-scientific clap-trap like graphology and personality tests that pervade the HR field.

9) Teach them to leave computers at home and get a real job, like starting their own business.

Something not mentioned

[Anonymous Coward]

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.

Re:DB Reports

[Meetch]

But only if they know at least some DB basics! Sometimes it is better that they at least run the query by someone familiar with how to write a proper query. Then, when they come to you screaming that the database is slow, and you see:

SELECT * from foo,foo,foo,foo,foo,foo,foo ...

Then you're perfectly within your rights to "retrain" them. With pliers.

Modifying examples

[pocari]

I taught a class on speech recognition application development for a while. Though the students were supposed to be programmers, sometimes extra seats would be filled by marketing types. They did fine for the first few days of the class where they had to modify, among other things, a simple C program. They also could peek at the solutions.

My boss at the time was the director of business development, a smart guy who could handle Excel macros and that kind of thing. He was good because he understood things from the lowest levels to the highest, and, thanks to the class, was the only executive in the company outside of R&D who actually knew what had to be typed to get an application to work.

While some posters seem to think it's dangerous to let business students experience success at programming, I think your students will have a better sense of accomplishment making limited changes to existing programs and scripts. Seeing things in context will give them a better sense of scale than the tiny demo-level things they could write themselves from scratch.

One warning, and something that has affected how I write code since then: every inconsistency in capitalization, indentation, variable and function naming, file locations, etc. will confuse somebody sooner or later. I started with programs from a variety of sources and had to clean them all up after a few runs of the course because students have a hard time knowing what's important and what can be ignored. (Besides C, we had a language for specifying what words could be recognized, and so even the experienced programmers had some new syntax to deal with.)

Re:Have them write a program...

[mwvdlee]

Funny as it may seem, the parent is right in that you might want to give them a scaled-down version of a real development lifecycle:

Deadline in 2 weeks.
1 week design time.
1 week building time.

And they'll have to figure out where the weeks of testing and implementation fit into the schedule themselves.

Actually you might want to organize them as a "real" team with:
Business manager (responsible for setting functional requirements)
Client (responsible for setting UI requirements)
Project manager (responsible for reporting and scheduling the project)
Designer (designing functionality)
Developer (typing code)
Tester (making sure implementation fits requirements)
Quality Assurance (making sure everything is documented and "clean")
Controller (the only person who can put a program on the production machine)
Security Officer (the only person who can set access rights to any hardware/software).

Now grade all these people for their own individual responsibility, do not grade them as a team or by the actual product.