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."
Every manager will profit from being able to make his own custom reports from company databases available to him. There are many databases in each company and the reporting abilities of current business software are very limited. Manager who can do a custom report for himself and even make it into a well generated web page for presentation to his superiors will definitely have an edge in his job.
If programs would be read like poetry, most programmers would be Vogons.
I don't need my boss to pull up a chair and sling out PHP script with me, but I DO need him to make sure my goals are clear, the customer knows what they are getting, and the schedule makes sense. The better he does THAT job, the better I'll do MY job.
--This sig is in beta. Please let us know abut any errors you find.
set up a group with arbitrary channels, i.e. Person A prepares the spec but has to meet with Person B for at least an hour to get it approved, once approved, the spec goes to Person C, who gives it to Persons D and E for actual coding. However, D and E have to go to Person C at least twice with questions, and C has to meet separately with A and B to answer these questions. Then C has to meet with D and E again to address the questions. (All of these meetings should be at least 30 mins.) Finally, D and E complete the project for review, at which time the teacher changes a requirement. And on...
Business Majors should love this....
I suppose such a course is OK but more often they infuriate me. Someone teaches a "business" class on web design. They hack together a bunch of pages in Word or FrontPage and then emerge as the sorts of bosses who wonder why they are paying so much for IT. Some people come out of these classes thinking "I can use the phone so I can probably run the phone system."
Constantly remind them of the myriad issues that you aren't covering like security, content management, error checking, reliability and failover techniques, good database design (OK, hard to do in a db with terrible bounds-checking, error reporting and such but you can try).
It would probably be very instructive to examine their apps and then show where they fail: "Look, I just retrieved all your customers phone numbers, bought lots of stuff for free and then purged your database."
You might also show your solution to the problem. It will probably be 10 times longer than theirs but will show the error-checking, user-friendly design and security features that they left out.
Finally, remind them that even thought they are doing very simplistic stuff it still requires someone to configure and maintain the network, servers and software.
On the plus side you are using open-source. The big impression you can leave the biz-school types is the cost comparison between Linux/BSD/PHP/Apache/PostgreSQL/etc. and the proprietary alternatives.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
In my experience, managers have a very hard time qualifying and quantifying the development process. I suspect your students will want/need the following:
1) basic understanding of computer/os architecture
2) basic understanding of programming logic
3) basic understanding of storage (eg: filesystems, sql)
4) enough skill to be able to solve one-off problems that *they* may have (as opposed to developing a system for someone else)
5) understanding of differing development methodologies.
6) security concerns and where they come into play
7) estimating time and scale of a project
The main concern, I think, is to get them to understand how to evaluate the scope of a problem and the types of resources that are required to solve it. I know a lot of managers that, given an IT requirement, would have to rely entirely on the IT staff to estimate the time and resources required to complete the task. They would have no way estimating it on their own nor could they predict or foresee problem areas that may lead to delays or product failures.
If you can make them think like programmers/designers or even just appreciate how developers think that is probably enough. It might even be instructive to take apart a large project (don't have them write it, have them dissect it and understand the basic pieces) so that they can get a feel for the types of challenges that developers face. Lets face facts, there is no point in teaching SQL or PHP to someone who has no immediate need for it. They won't remember it and the arcane details they pick-up won't actually help them when they attain the types of positions they truly want. If you can distill into them even some comprehension of the real work of developers you stand to help both developers and managers.
If you want to have managers who can program, hire a programmer. And don't, as so many others have suggested, give them a lesson in how fucked up and terrible it is on us poor programmers (ex: make them write something and then change the scope on the last day, ask them to do something in an impossible amount of time, ...)
Remember that concept of abused kids growing up to be abusers? I think it applies here.
Teach them about how interfaces and implementation hiding work, teach them about how programmers divide up work, and how modules can depend on each-other, and about unit testing. Teach them how difficult it is to estimate (time, cost) on a software project.
Teach them about programmer _culture_, what programmers value and what they disdain.
Teach them to play with scripting, not programming -- teach them how to build bigger functions out of smaller ones.
Teach them how to recognize a great programmer, and then trust him/her to deal with the programming side of things.
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.