Teaching Programming to Non-Developers 74
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?"
Have them write a program... (Score:5, Insightful)
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."
Re:Have them write a program... (Score:5, Interesting)
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.
Re:Have them write a program... (Score:4, Interesting)
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.
DB Reports (Score:5, Insightful)
Re:DB Reports (Score:3, Insightful)
Re:DB Reports (Score:1)
But even with just raw SELECT access, managers can place themselves in sticky situations, gining them access to information that they are not supposed to know, like salary information, location of the personal residence of that "hottie" in logistics, sick-leave details (OMG that guy has what?), and other private information. The scariest part of this is with SOX legislation; he could blab about something sitting in some database t
Re:DB Reports (Score:2)
Re:DB Reports (Score:3, Interesting)
SELECT * from foo,foo,foo,foo,foo,foo,foo ...
Then you're perfectly within your rights to "retrain" them. With pliers.
Re:DB Reports (Score:1)
With dozen's of reports floating around (written by different managers), much of my time is spent explaining to PHBs why Report A and Report B don't tie-out when they are extracting almost, but not quite the same data.
Not to mention the amazing ability of a little bit ow knowledge resulting in a query from hell that brings even the mightiest Oracle database to
On what planet? (Score:2)
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.
Where in this galaxy is there a "manager" who is capable of writing a "custom report for himself"?
I deal wit
Re:On what planet? (Score:2)
I thought we were talking about the real world. (Score:2)
Although the fact that I work for Oracle can possibly have something to do with that...
Cheater.
Re:DB Reports (Score:1)
be sure speak in their language (Score:3, Funny)
You have to use words like "incentivize" and every sentence must contain the phrase, "at the end of the day".
Re:be sure speak in their language (Score:5, Funny)
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.
Re:be sure speak in their language (Score:1)
Re:be sure speak in their language (Score:2)
Although, I must admit that real local government contract s make this seem like kindergarten haiku.
Re:be sure speak in their language (Score:1)
Requirements (Score:5, Interesting)
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.
The why part is important. (Score:2)
If they think that what they are learning will be useful, then they will remember it.
Re:The why part is important. (Score:3, Insightful)
Printing hello world, outputting today's date on a web page or anything boring and useless like that is bound to be quickly forgotten.
Oh, for the love of dear God, please do not do this. I might even go as far as to counsel considering not walking them through anything that produces a finished product. This gives them a reason to rationalize once they are in the real world, "hey, even I could do it back in B-school...", and it is all downhill from there.
One of my most difficult and intractable communica
Re:The why part is important. (Score:4, Insightful)
Man, I love this idea. This would be a fantastic concept that would be beneficial to both types of students... especially if you "teamed" them up with a manager and engineering lead having to work together.
Coming from the two different viewpoints they offer competing visions, and different expectations. It would also be a part of the curriculum, as they are going to be graded differently on the performance of the two groups of people. And with the management "trainees" it would be a good exercise for learning how to make a good requirements definition document that could be understood by an engineer... not normally something taught in universities, together with when and how requirments can be changed, and what the consequences of doing that are going to have on completing the project... all management skills that both managers as well as engineers should be aware of. It would be better for a manager to screw up in school than learn this for the first time on a $1 Million project (rather small and typical for a first time manager). There are other things too, like when to pull back and takes hands off a project, when to throw parties, utilizing team assetts, helping discouraged team members (true leadership skills here), and how to simply remove somebody when they aren't working out (that is not always an option... even in the "real world").
These are all skills I wish I had learned when I was in school... but instead had to learn through the school of hard knocks... often with incredibly lousy managers to boot.
Re:The why part is important. (Score:2)
Teach them to lead... (Score:5, Insightful)
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.
The obvious answer... (Score:2)
Natalie Portman, grits, and Michael's biography. If the students are Korean, replace Portman with Katie Holmes. Be sure to repeat your lecture at least 3 times a week, each time using a different lecturer.
throw in some red tape...... (Score:4, Insightful)
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....
Don't teach them programming. (Score:5, Informative)
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
Re:Don't teach them programming. (Score:1, Funny)
Re:Don't teach them programming. (Score:3, Insightful)
(though
Time vs. Money:
* In-house vs. Outside development
* Creating a new system vs. Adapting existing system (which may cost)
was great)
Any technical information won't matter to them at all. They're gonna be fresh out of school, and all those choices will be made for them by either: the business they get hired into, which has all this stuff more or less in place already; or the tech folks at the startup they go to, whose job it is to mak
Remind them of the real world (Score:5, Insightful)
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.
infosecurity basics (Score:5, Informative)
Show them what it means (Score:5, Insightful)
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.
Re:Show them what it means (Score:1)
Make them suffer (Score:2, Funny)
No, I don't work at EA. Why do you ask?
*twitches*
no, no, no. (Score:5, Insightful)
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.
Programming for Managers 101 (Score:2, Interesting)
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!
Hmmm... (Score:2)
Step 3. Make the business requirements clear, valid, non-conflicting, and technically viable
My experience has been that this step always gets done in reverse: The programmer assesses the situation, decides what the "business requirements" are, and then, when he's finished creating the solution, that solution becomes the "business requirement", or even the "business model" itself.
I.e. the programmer is the only one on the team with an IQ sufficient to imagine and then create a business structure; the ma
just... (Score:1)
"Well the paradigm shifted again, brick and morter are back and people want face to face contact, So today we will be going out in the parking lot and learning correct steps for brick vaneer wall construction"
Teach them to think first (Score:5, Interesting)
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.
A PHP course for B students is malpractice (Score:5, Insightful)
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.
Re:A PHP course for B students is malpractice (Score:1)
Remember... business students grow up to be the managers who say things like "Give me the 'executive summary' of the work involved in this project... I know you've spent the last two months just understanding the requirements, but I'm in management and therefore, by definition, am infinitely smarter than you programmer worms, so I can absorb it in just a few minutes".
Although I admire everybody's suggestions to try to make them into decent human beings, I think you're probably fighting a losing battle here
shoot them...all of them (Score:1)
Teach the basics first! (Score:1, Interesting)
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
software engineering (Score:3, Insightful)
Saying well written code is valuable is one thing, but since you are actually teaching PHP and MySQL you have the ability to show it. Were you doing a more capable language like Java/JSP or ASP.NET I'd say also show them how valuable separating things into designed layers and concerns is in software engineering, but PHP isn't very capable in that area and you probably don't have time to teach OOP and UML and whatnot anyway.
Re:software engineering (Score:2)
Lots of managers don't value well written code. Get it done and get it done fast is the rule they enforce. Maybe a segment where you give them two different scripts, one with traditional spaghetti code/long functions/poor naming, etc. and one with well written and documented code. Then ask them to fix certain bugs in the scripts or add certain features.
Have them implement something individually, then give their code to someone else and vice versa, and totally change the requirements on them at the last m
Don't teach them *programming* at ALL. (Score:4, Insightful)
INSTEAD, do THIS:
Arrange the course around a 50,000 foot view of the actual development process. Show the managers what programmers actually have to put up with, what problems they have to endure, what sorts of things go wrong in their daily lives that gum up the works and cause projects to fail. Show the managers good project management practices. Instill a sense in them that all schedules are works of fiction until their projects are complete (forecasting is a myth!). Make sure they understand that in software development, anything that can go wrong will, and that it's not necessarily the programmer's fault. Show them what happens when a user changes everything right in the middle of a project, so that the manager will have a proper fear of such catastrophes. Teach them that hiring permanant staff results in the retention of institutional knowledge about the applications in use, and that outsourcing (even to local consultants) ensures that NO institutional knowledge will ever be developed or retained. Teach them HOW to hire consultants if they do -- how to develop their bullshit detectors and know when they're being lied to, for instance.
In other words, don't try to make a manager a programmer (it can't be done). Instead, try to make the manager into the kind of manager YOU would want to work for. Teach them how to manage smart people, and how to treat them well, so that they're respected and followed rather than defied, hated, and surreptitiously mocked as "The PHB".
Then, the manager's eventual staff will bless you again and again. All that good karma's gotta boomerang back and whack you SOONER or later.
Re:Don't teach them *programming* at ALL. (Score:2)
Re:Don't teach them *programming* at ALL. (Score:3, Funny)
But to do it right, you'd have to set it up like the Sims:
* Different development groups would drop by for a visit, and the two groups of programmers might get along well, or suddenly attack each other (complete with spherical cloud of smoke).
* Different managers would come by to try and poach your best people (like the Sims thief). Instead of a burgular alarm, maybe you'd get a vicious, paranoid office manager compl
Re:Don't teach them *programming* at ALL. (Score:3, Funny)
Re:Don't teach them *programming* at ALL. (Score:2)
I last worked with developers in an advisory rather than managerial position, but the issues are similar and my experience is that I worked better with developers because I knew how to progam a little. This is not an illusion of my own, it is what the developers told me.
Re:Don't teach them *programming* at ALL. (Score:2)
After entering the civilian world, this changed and I came to value "most" of my technically astute managers. (At least those that did not micromanage.)
There are two key differences in
Re:Don't teach them *programming* at ALL. (Score:2)
Developers tell their managers whatever their managers seem to want to hear, because managers decide who gets raises and who gets laid off.
Don't be so naiive.
Something not mentioned (Score:5, Interesting)
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.
How about teaching to Architects? (Score:2)
Try Higher Level Topics (Score:1)
Uhhhh.... (Score:2, Informative)
Teach them to write Requirements and Use Case Docs (Score:3, Insightful)
Teach them to write really good Use Case documents. To really think through the scenarios for their programming project.
Have a set of programmers - who are really good - look at their requirements and use case documents and tell the Managers what they think they are building based on their documents.
They are managers. They need to be able to effectively communicate directions and needs to programmers. So teach them to communicate and document.
Or, teach them to hire good I.T. Architects to do it for them.
PHP? MySQL? (Score:2)
Have you considered teaching them to program a system they already understand? Everybody knows how to use a word processor or a spreadsheet, and these programs usually come with scripting engines. Hack
Original poster response (Score:3, Informative)
What was particularly interesting were the posts with the perspective (reflecting my experience) that while you can't really teach the full coding aspect (most students coming in weren't even familiar with HTML) there is certainly value to be had in understanding programming methodology. But there's also value to be had in teaching the managerial perspective.
So what to do with only a limited amount of class time?
I actually did have the class do a large-scale simulated project last term. While the project itself didn't wrap at the end, the students have already said that they have a much greater appreciation for requirements documentation, testing processes, active management of lines of communication, and other less obvious aspects of development.
But many did express a desire to learn more code, which is problematic given that you can't easily go from HTML 101 to PHP/MySQL in a few weeks. And I chose PHP/MySQL in part because that's what I'm most familiar with, but also because the school is an MS shop and they haven't had any experience with open source. Given those parameters, we never even touched on some of the excellent suggestions made by others re: availability, failover, scalability, 'real' OOP, anything more than basic security...
I really liked the idea of hooking up the students with a CS class. I also am gravitating towards the less-code approach, though the students have already said that they wanted more code and less replication of what they had experienced in other business-oriented courses.
And as a personal note to those questioning the course itself: I'm adjunct, defined as "s/he who gets paid a token sum without benefits to teach a predefined course in an established program." It hath been determined that the business students will learn web application programming, therefore they shalt learn web application programming, and that's the gig.
Anyway, so here's where I'm leaning. Structure the course so that 30 managers (the students) are managing one developer (me). Each lecture is wrapped around understanding a specific aspect of the development process. Their assignments are built around learning enough tech to understand what is going on, being able to demonstrate an understanding of the complexities of the process, and the how code and business practices impact one another.
Again, thanks everyone for participating. Any more thoughts?
Show them this XP web page [& site]... (Score:2)
http://eXtremeProgramming.org/rules.html
& let them go from there to topics of interest
Modifying examples (Score:3, Interesting)
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.)
Teach them that experts know their stuff (Score:3, Insightful)
Re:Teach them that experts know their stuff (Score:2)
Re:Teach them that experts know their stuff (Score:1)
You forgot the follow-on meeting to "brainstorm options for meeting the deadline/determine why development is taking so long". This meeting is scheduled for 6 PM because "everybody's calendar is booked solid during normal working hours". All options that will actually work go into the "long-term solution bucket", and short term solutions such as working on the weekends/holidays/evenings are solicited.
Teach them REAL programming (Score:1)
(The history courses I took weren't "history lite" because the instructors new I wasn't going to be a full time historian.)
More importantly, don't teach them some RAD system. Teach them how a large scale/scalable project is developed. Teach them when RAD is not applicable & why.
Yah, but History courses DO get tailored.... (Score:1)
PHP + MySQL + n00bs = security nightmare (Score:2)
Best possible thing to teach future IT managers... (Score:1)
Teach them to speak Hindi.
or (Score:1)