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.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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....
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 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
I taught a one-semester PHP and MySQL basics course a while back and you may find the materials there helpful. If I had to distill the most important parts down for non-coders, I'd emphasize confidentiality, integrity, and availability as the most important properties of an information system.
http://tinyurl.com/4ny52
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.
You're not thinking outside of the box and taking a holistic approach. You also have to consider the end-user experience in a thin-client multi-tiered environment and make sure it is 24/7. Otherwise you are not utilizing the Web applications infrastructure to its full potential.
I'd also teach the staff to optimize, the quality, performance and availability of pre-deployed applications across the entire project lifestyle, with important milestones including testing, tuning deployment and management of baseline targets . Functional, load, performance and scalability testing for business-critical deployment stages are critical in order to assess end-user experience with online transactions and service-level agreements.
With Enterprise-class cross-product applications the only way to keep going forward and get the maximum leverage while adding value and still maintaing competency in is to consult with all involved departments. Then you can run each idea up the flagpole, creating synergies and pushing the envelope of systemisation and business continuity at the same time. Finally you can take a heads-up view of the direction that the project is going and increase productivity (n)-Fold.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
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.
Can You Say Linux? I Knew That You Could.
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.