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
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 communications issues as a programmer and salesman (yes, I do both) is quickly and concisely conveying the amount of effort involved to respond to requests from my Clients, and why that effort is necessary to meet their request. The hardest cases have always been managers who know enough to be dangerous, and are bewildered when their assumptions don't pan out after they scale their small amount of knowledge to production-grade, enterprise-scale settings.
The suggestions to throw them into a small (1 week) project and change requirements late into the project are good, but need refining. You don't want to traumatize them into believing that software is impossible; they'll be paralyzed when it comes time to make a decision. You are there to teach them tools for managing development practices, not actually carry out the development.
Have you considered going to your school's CS (or better, MIS if they have one, because odds are slim most of your B-school students will go on to manage or interact with teams of CS graduates) department, and finding a professor teaching a software engineering class who is willing to integrate some/all weeks of his syllabus with your class? Most root cause issues with software development/deployment projects arise not between the direct interaction between the development lead (your students in this case) and his programmers (hopefully some MIS/CS students), but rather from pressures (economic, business, or political) originating from outside the team.
Carefully craft a series of exercises where you play the role of the demanding Client. They are the development team; ideally you are going to play the role of Client to as many different development teams as there are B-school students. Like any good teacher, you're going to have to sweat bullets ahead of time to come up with concise lessons through role-playing and assignments to accomplish your goal. Through your Client-team relationship with them, teach them how to negotiate requirements (i.e., knowing when and how to say "no"), how to evaluate and make technical trade-offs based upon feedback from their technical specialists, project management in a software project context, etc. Teach them about all the pressures that will tempt them to cut development practice corners. And make it damn, damn hard for them to stand their ground, as realistic as you can figure how. Threaten to "fire"/flunk them out of the class, entice them with bonuses to meet unreasonable (but not obviously so) demands, etc.
Then and only then, show them how that dovetails into development practices at the technical specialists' level (version control, agile methods, usability testing, software testing, whatever you want to expose them to), so they understand that these development practices have an immediate bottom line impact, and how much of an impact these practices make on the development effort. Showing them how to measure the impact, and how managing by metrics instead of using the metrics as another tool in their management arsenal will entrap them into a project management hole they will never dig out of, would be a bonus. Your MIS/CS counterpart should have a similar course plan that shows those students how to "manage upwards", communicate and think in business terms, convey a professional demeanor even when making a forceful point, etc.
If you and your MIS/CS counterpart are really good, you would try to find out what gets your respective student
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.
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.
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.
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.
Teaching a manager programming gives the manager a false sense of competence. He may develop the idea that he actually knows what all this programming business is about, and it'll make him an insufferable pain in the ass to all of his developers, who will curse your name in several languages for decades. Don't do it! Think of it as a "professional courtesy" issue and don't curse your comrades by creating such a monster.
:)
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.
Farewell! It's been a fine buncha years!
Skip the basic programming. Teach them how to write good requirements documents. Teach them that small changes (in their minds) mean big changes in code. Ask them what effect the change in the requirement that "all users will be inside the company" (and thus inside the Authentication/Authorization system / directory) to "some users may be outside the company" (suddenly need a way to get these users into the system and to manage their accounts and access).
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.
That's great advice! Though I might have gone even higher:
(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 make these decisions.
Teach them how to write specs.
Teach them how to talk to programmers (tell them what they need, want, would like, and make each clear).
Teach them how to listen to programmers (ask about pros/cons, options, costs).
Explain to them that they get to choose a ship date, or a feature set, but not both.
For the business folks, design and process is WAY more important than ANY amount of coding information. Frankly, it should have been emphasised more back when I was in CompSci - but that was the late 80's, and I hope (and doubt) that it has changed.
How often do managers insist they know better? It really gets me down. If you hire a mechanic to work on your combine harvester and he says he needs a three eighths Gripley, then this means he sodding needs a three eighths Gripley, not some new tool you've just plucked out from where the sun don't shine. Trust your experts to know what they're talking about, don't try to do their jobs for them, and don't try to micromanage them.