Slashdot Mirror

← Back to Stories (view on slashdot.org)

Teaching Programming to Non-Developers

Posted by Cliff on from the illumination-of-the-non-enlightened dept.

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

74 comments

  1. Have them write a program... by Anonymous Coward · · Score: 5, Insightful

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

    1. Re:Have them write a program... by maeglin · · Score: 4, Interesting

      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.

    2. Re:Have them write a program... by mwvdlee · · Score: 3, Interesting

      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.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  2. DB Reports by aralin · · Score: 4, Insightful

    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.
    1. Re:DB Reports by kalidasa · · Score: 2, Insightful

      Just make sure you don't give them INSERT or DELETE permissions to those databases.

    2. Re:DB Reports by Anonymous Coward · · Score: 0

      update foo set bar=1;

      (26,485,349 rows updated)

    3. Re:DB Reports by Meetch · · Score: 2, Interesting
      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.

    4. Re:DB Reports by Leadhyena · · Score: 1
      Or UPDATE even...
      update EMPLOYEES set SALARY=2*SALARY where NAME="Joe Blow"
      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 that's really important to the stock price to his friend, and then all hell breaks loose, because not only do you have to suffer the embarassment of seeing the inside trader get carted off but also if you're the sysadmin you better be able to pull up all of his conversations that day on all protocols or possibly be faced with a nasty fine. It's scary enough that some managers are given a copy of Crystal Reports or Impromptu with a root password to the database and are told to go to town. My conclusion is that no manager should be taught how to use SQL for their own deniability in mischief, except for the CIO, and he should have access to as little as he needs, so he is not found culpable. Information is a lot more dangerous than it used to be.
    5. Re:DB Reports by HomerJayS · · Score: 1

      You would be amazed at how quickly a business user with a little SQL knowledge and read-only accees to a database can make IT's life a living hell.

      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 its knees.

    6. Re:DB Reports by MindStalker · · Score: 1

      Hu? No, your manager should know how to use SQL. Its your database that should provide this security, not the frontend, and especially not the lack of knowledge of your database. Someday some lacky employee will be hired who knows SQL but you don't know it, and they will happily take this information.

    7. Re:DB Reports by nb+caffeine · · Score: 1

      Agreed. If my coworkers could create reports themselves (or update them, as it were) then a large amount of my time would be saved. hey, if you teach them crystal, send their resumes my way, will ya?

      --

      "Something's wrong with you...and I hope we never do meet again." - Deftones When Girls Telephone Boys
  3. be sure speak in their language by sfjoe · · Score: 2, Funny



    You have to use words like "incentivize" and every sentence must contain the phrase, "at the end of the day".

    --
    It's simple: I demand prosecution for torture.
    1. Re:be sure speak in their language by mikael · · Score: 4, Funny

      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
    2. Re:be sure speak in their language by quamaretto · · Score: 1

      Is that really the best you can come up with? You need to have a poke through "The Dilbert Principle" and maybe try again, because I understood most of that and I know which parts are nonsense (And which parts are just bad management).

      --
      *is run over by rotten tomatoes*
    3. Re:be sure speak in their language by mikael · · Score: 1

      Interesting. I scanned through a list of web pages and buzz-word dictionaries to get a set of words, then glued the words into an order than would appear to make sense.

      Although, I must admit that real local government contract s make this seem like kindergarten haiku.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    4. Re:be sure speak in their language by quamaretto · · Score: 1
      Interesting. I scanned through a list of web pages and buzz-word dictionaries to get a set of words, then glued the words into an order than would appear to make sense.
      Nonono, you proactively leveraged interactive datums and utilized them to cross-develop your synergistic information resources. You'lll never get anywhere if you talk all boring like that.
      --
      *is run over by rotten tomatoes*
  4. Requirements by bill_mcgonigle · · Score: 4, Interesting

    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)
  5. The why part is important. by BigZaphod · · Score: 1

    Why are they in this class to begin with? Figure that out (or, assuming you know already), then make the project into something that will seem useful to them. Printing hello world, outputting today's date on a web page or anything boring and useless like that is bound to be quickly forgotten. Show them something that makes sense for them in their domain that relates to why they are there.

    If they think that what they are learning will be useful, then they will remember it.

    --
    Hexy - a strategy game for iPhone/iPod Touch
    1. Re:The why part is important. by tyen · · 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 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

    2. Re:The why part is important. by Teancum · · Score: 3, Insightful
      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.


      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.
    3. Re:The why part is important. by sakshale · · Score: 1

      I have to add my vote to this one. Teaming up the student in both programs is an excellent idea!

      --
      For every problem there is a solution that is simple, obvious and wrong.
  6. Teach them to lead... by ShamusYoung · · Score: 4, Insightful
    Rather than focusing on "coding", I would rather they learn about the problems they will be able to control: Vague requirements, shifting feature lists, improbable timetables. Teach them a bit of code and use THAT knowledge to teach them the importance of a well-managed project.

    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.
  7. The obvious answer... by Rahga · · Score: 1

    "So what would the Slashdot community recommend within the curriculum?"

    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.

  8. throw in some red tape...... by ahowl · · 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....

  9. Don't teach them programming. by bensyverson · · 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

    1. Re:Don't teach them programming. by Anonymous Coward · · Score: 1, Funny
      You forgot:

      • Hiring Developers
        • Beard vs No Beard
        • Prattles on about patents vs Talks about girlfriend
        • That smell: What it is and what it means
    2. Re:Don't teach them programming. by kwerle · · Score: 2, Insightful

      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.

  10. Remind them of the real world by linuxwrangler · · Score: 4, Insightful

    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
  11. infosecurity basics by ubiquitin · · Score: 4, Informative

    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
  12. Show them what it means by xoboots · · Score: 4, Insightful

    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.

    1. Re:Show them what it means by ibman · · Score: 1

      Or just copy the curriculum for the local university's cs 101 class: computer science class for non-cs majors.

  13. Make them suffer by Anonymous Coward · · Score: 2, Funny

    Now is your chance. Make those 'managers-of-the-future' suffer for all the pain they will cause us. Force them to stay awake for 72 hours finding obscure bugs in code older than themselves. Get a megaphone and yell at them non-stop about upcoming deadlines. Have them chew raw coffee beans before giving them a stack of yesterdays pizza's for dinner.

    No, I don't work at EA. Why do you ask?

    *twitches*

  14. no, no, no. by dynamo · · Score: 4, Insightful

    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.

  15. Programming for Managers 101 by Glonoinha · · Score: 1, Interesting

    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!

    --
    Glonoinha the MebiByte Slayer
  16. just... by mbrewthx · · Score: 1

    Walk in one day with your head down and say..
    "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"

    --
    __________ Leave me alone I'm compiling a RPG II program on my S/36...Thanks to metamucil I'm a Regular Meta Moderator
  17. Teach them to think first by macemoneta · · Score: 4, Interesting

    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.

  18. A PHP course for B students is malpractice by OldAndSlow · · Score: 5, Insightful
    Educational malpractice! Does your school offer a one term course in chip design for business majors?

    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.

    1. Re:A PHP course for B students is malpractice by computational+super · · 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 - no matter what this guy does, they'll be in management, therefore superior. Meanwhile, everybody who can actually accomplish something is busy doing instead of "managing".

      --
      Proud neuron in the Slashdot hivemind since 2002.
  19. shoot them...all of them by omibus · · Score: 1

    Trust me, humanity will be better for it.

    --
    Bad User. No biscuit!
  20. Teach the basics first! by Anonymous Coward · · Score: 1, Interesting

    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.

  21. software engineering by pocopoco · · Score: 2, Insightful

    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.

    1. Re:software engineering by Scarblac · · Score: 1

      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 minute so they have to do impossible changes to the other guy's unreadable code.

      Afterwards review the code, show how it should have been setup so that it would be comprehensible to someone else, and easier to change. That should drive the point home.

      Heck, that's not for managers, that's something to do to 1st year computer science students.

      --
      I believe posters are recognized by their sig. So I made one.
  22. Don't teach them *programming* at ALL. by crazyphilman · · Score: 3, Insightful

    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!
    1. Re:Don't teach them *programming* at ALL. by Associate · · Score: 1

      Why don't you write a development simulation to do this. Call it SimiDevelopment. They can manage the various aspects of the project, hiring more coders and consultants, having the network turned into a botnet ala Godzilla in SimCity... How meta would that be? Have them play this game that incorporates the real world issues between developers, managers, customers and stock holders. It would undoubtedly have an anti-management slant, but I think that a good thing.

      --
      Someone hates these cans.
    2. Re:Don't teach them *programming* at ALL. by crazyphilman · · Score: 2, Funny

      I smell a commercial game, there... That's something people would pay good money to play.

      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 complete with a bun in her hair and two inch blood-red nails on her fingers.

      * You'd have to monitor your programmer's mood and general well being. If you didn't keep them happy, they would either drop dead at their desk (Karoshi) or they would sneak off and join competing firms.

      * Like Sims trying to cook, periodically consultants will set the mainframe on fire, then jump from foot to foot with their hands in the air instead of doing anything about it. If you purchased a Source Control System, it would act like the Sims fire alarm -- and a sysadmin would activate the halon system (putting out the fire and killing the consultant, thus solving the problem and preventing future ones).

      * Finally, hackers would periodically sneak in and try to charm one of your workers (or the sadistic office manager). Your IDS would go berserk and a security guard would come running in and nab the hacker. Or, if you didn't buy one, the hacker would steal your development server, knock up all your workers, and reduce your revenues by 50%.

      Sounds fun!

      --
      Farewell! It's been a fine buncha years!
    3. Re:Don't teach them *programming* at ALL. by the_womble · · Score: 1
      manager programming gives the manager a false sense of competence

      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.

    4. Re:Don't teach them *programming* at ALL. by Associate · · Score: 2, Funny

      We could also add team member selections like in fighting games where you select the strike team. A resume and general description could be used as specs. You possibly could use more, but that would violate some EEOC rules. Plus, it adds a bit of chaos to a otherwise predictable system. Bob has 5 years experience in Win2k3 Server and a meth habit. Jenny knows all the latest languages and must pick up her kids from day care by 4PM every afternoon. She also cannot work weekends. Eugene will work for $5k less than everyone else and 55+ hours a week, but he smells bad.

      --
      Someone hates these cans.
    5. Re:Don't teach them *programming* at ALL. by sakshale · · Score: 1

      When I was in the Navy, working as an enlistedman in a technical field, I hated it when our division had an officer who had an engineering degree. They always assumed they understood the full technical requirements and tried to micromanage our day to day lives. ( This was before the term "micromanagement" was invented. :)

      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 those environments. First, the military tends towards micromanagement by (unofficially) teaching its officers that they are "elite" and better than the enlistedmen. Second, and most important, the technical requirements are clearly defined by an external agency and relatively unchanging. Most technicians can and do deal with problems quickly and effectively. (Field stripping a gun comes to mind.)

      Having an "engineer" come in and introduce ad-hoc changes to support requirements, that directly contradict the mandated, external requirements, leads to chaos very quickly.

      --
      For every problem there is a solution that is simple, obvious and wrong.
    6. Re:Don't teach them *programming* at ALL. by Anonymous Coward · · Score: 0

      Yeah, I think your developers were being nice to you. I suspect your programmers liked you because you stayed out of their hair and didn't get on their nerves. Not that there's anything WRONG with that. It's really the ONLY way to get a programmer to like you. A really great way to get a programmer to lose all respect for you is to say something like (actual quote from a university president I worked under once): "Oh, I'm a programmer, I go way back with this stuff... I used to use DB3, you know..." He could have meant the Berkeley database, 3rd version, or he could have meant an old Dos tool I've heard about (probably the latter). Regardless. It was like a "kick me" sign.

      However, I will say that when a manager is a former developer (NOT a B-school grad), most programmers will get along very well with that manager because he's one of them. It's the same exact phenomenon as the "Stallion" -- the Marine Corps enlisted guy who goes back to college, gets his degree, and comes back as an officer. They're much better officers because they started out as grunts, and UNDERSTAND.

      In contrast, no B-school grad will EVER understand what his programmers are doing, much less what their work requires, no matter how much time he spends in a toy course in programming. If he tries to talk the talk, it'll take his developers about thirty seconds to realize he doesn't walk the walk, and they're going to have an enormous amount of fun setting him up as the straight man in their comedy routines.

      Programming isn't a skill you can fake. Knowing a tiny little bit is worse than knowing nothing. It's just lots of rope to hang yourself with.

    7. Re:Don't teach them *programming* at ALL. by crazyphilman · · Score: 1

      So, it's not an illusion of your own, it's one they gave you. :)

      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.

      --
      Farewell! It's been a fine buncha years!
  23. Something not mentioned by Anonymous Coward · · Score: 5, Interesting

    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.

  24. How about teaching to Architects? by n-baxley · · Score: 1

    We have an architect working for our small web company and he's been picking up bits and pieces of the coding and network management, but sometimes I feel that he doesn't quite get the overall concepts. What would the best approach to getting him into a programming mindset? Obviously we don't want to force him into something he doesn't want to do, but we really like his work ethic and hope to be able to use him for some more areas like programming and networking. Any ideas?

    --

    THIS SPACE FOR RENT
  25. Try Higher Level Topics by CaptMattman · · Score: 1

    I would try higher level topics in the web programming arena since the target audiance is management who tend not to be technical. Maybe show them how a front end web interface passes data to specific tables/fields in your MySQL tables so they get a feel for the pain you endure when challenged with designing and supporting such an interface.

    --
    -Mattman
    http://OneBillion.blogspot.com
  26. Uhhhh.... by Anonymous Coward · · Score: 2, Informative

    If they're attending a "local public university" and their "professor" is asking Slashdot to develop his curriculum, then these students are clearly not the "mangers of the future."

  27. Teach them to write Requirements and Use Case Docs by hobbestcat · · Score: 3, Insightful

    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.

  28. impossible by Anonymous Coward · · Score: 0

    The students are seniors in the business program; the course is intended to expose them to development practice

    Your goals are too high given the context of the course. If you were trying to teach them html, css, basic programming, php, xor sql, I could understand that. I'm not sure any of these subjects have a great value proposition for a business student (maybe sql), but individually, on their own, they sound potentially achievable. A business student could learn sql and some database basics in a quarter. However, there's no way to accurately expose these people to development practice in the context of web development given that they probably know next to nothing about the above topics. The only way I can think of to accomplish what you want would be to embed your students with professional software development teams. They wouldn't have a clue about the technical details, but they would be immersed in a group of people who did and were presumably organized enough for actual development process characteristics to be witnessed. Teams of Computer Science students really do not count.

  29. PHP? MySQL? by fm6 · · Score: 1
    If your goal is not to turn people into developers, why are you teaching these tools? PHP is an arcane scripting language that requires a pretty good knowledge of HTML and HTTP to be useful. SQL is a declarative language full of subtle DBMS concepts. Talk about throwing people in at the deep end of the pool!

    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. Hacking in a new feature or two to Open Office is a more accessible homework assignment than writing a database-driven web application!

  30. LAMP model by some+guy+I+know · · Score: 0, Troll
    show them what the LAMP model is all about."
    Then show them what the EASY CHAIR model is all about.
    Then the END TABLE model.
    Then the CREDENZA model.
    Etc.
    Also things like the NUMBER 2 PENCIL model, the YELLOW LEGAL PAD model, and so forth.
    You can find models for all of these items, and many other exciting items, at various 3D game mod sites.

    On a more serious note, for those who don't know, "LAMP model" means "Lick-spittle Ass-kissing MBA Prat model".
    --
    Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
  31. Original poster response by pdxluddite · · Score: 3, Informative

    I won't be able to do justice to all the insightful and interesting comments above, but let me at least thank everyone for participating.

    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?

  32. Show them this XP web page [& site]... by ivi · · Score: 1

    ...on eXtreme Programming's Practices & Rules:

    http://eXtremeProgramming.org/rules.html

    & let them go from there to topics of interest :-)

  33. Modifying examples by pocari · · Score: 3, Interesting
    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.)

  34. Teach them that experts know their stuff by jazman · · Score: 2, Insightful

    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.

    1. Re:Teach them that experts know their stuff by jazman · · Score: 1

      And don't insist on meetings every fscking five minutes when there's a major deadline approaching. "It's urgent so we need you to sit in this room drinking coffee with us and waffling about an endless string of maybes instead of actually getting on with it" really makes managers look stupid.

    2. Re:Teach them that experts know their stuff by computational+super · · 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.

      --
      Proud neuron in the Slashdot hivemind since 2002.
  35. On what planet? by mosel-saar-ruwer · · Score: 1

    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 with people who have Bachelor's, Master's, MD's, and PhD's, and they can't even do basic stuff like point and click. Hell, I've dealt with "computer" guys [sporting Bachelor's and Master's in "computer" fields, like math, EE, etc.] who are utterly clueless.

    If you're with an outfit that has managers who are smart [and competent] enough to write their own "custom reports", then I'd say: Go very, very long on whatever stock options they've granted you.

    1. Re:On what planet? by aralin · · Score: 1

      Hey, my manager can do that and he is even better at it than I am. His manager can do that quite easily. The manager of his manager (we talk VP here) can do it and not break a sweat and his manager can most certainly do it. And his manager, our CEO , can do it as well or better. So I don't know about you, but all the way up my chain, every manager can do it. And in fact, I could not, with confidence, say that I can do a better job than either of them. Although the fact that I work for Oracle can possibly have something to do with that... :)

      --
      If programs would be read like poetry, most programmers would be Vogons.
  36. Hmmm... by mosel-saar-ruwer · · Score: 1

    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 management team exists solely for the purpose of enforcing [on the "employees"] the structure created by the programmer.

    Step 4. Give the developers a good development environment (hardware, software, and surroundings)

    This is really key: Don't go telling people that you're embarking on some big new project that's got all these great funding guarantees from the suits who live higher up the food chain, and then try to nickel and dime them to death on the things they need to get the job done:

    "Sorry, we don't have any money in the budget to get you a keyboard with keys that don't stick..."

    "Sorry, we don't have any money in the budget to get you a chair that isn't broken and doesn't cause your back to ache incessantly every day you sit in it..."

    "Sorry, we don't have any money in the budget to purchase you a dual [or triple] head video card and two [or three] monitors so that you can see your work on screen..."

    "Sorry, we don't have any money in the budget to purchase the Developer's Kit. Here, use this 30-day trial evaluation package they sent us, and just remember that at the end of every month, you need to set the date on your computer back to January 1, 2003..."

    "Sorry, we don't have any money in the budget to give you an office. Here, sit at this bench along with the secretarial staff and share this computer with the receptionist..."

    I mean, if the money isn't there, then don't undertake the fsck-ing project in the first place.

    And sure as hell don't go jet-setting all over the damned globe to your precious "conferences" while your technical staff are being denied the hardware they need to get the damned job done.

  37. Teach them REAL programming by rfisher · · Score: 1

    Don't treat them differently because they aren't going to be full time programmers. Just teach them to program.

    (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.

  38. PHP + MySQL + n00bs = security nightmare by JaF893 · · Score: 1

    If you start teaching them how to write PHP code then teach them how to write secure code from day one! Warn them of the dangers of Cross Site Scripting (XSS) and MySQL injection etc. See here for more security related issues.

  39. Best possible thing to teach future IT managers... by nganju · · Score: 1


    Teach them to speak Hindi.

    --
    There are 2 kinds of people in this world. Those that can keep their train of thought,
  40. I thought we were talking about the real world. by mosel-saar-ruwer · · Score: 1

    Although the fact that I work for Oracle can possibly have something to do with that... :)

    Cheater.

  41. Yah, but History courses DO get tailored.... by sure_fang · · Score: 1

    History gets tailored thru its subject matter. I bet you attended a lot more "Overview of the History of the Euro-world" than you did "Social History of the Song Era Chinese Peasant"-type courses. And in thoses courses where you *did* attend, i guarantee you got off with easier grades on lighter theses than did the hardcore history majors.

  42. Idiot mods by Anonymous Coward · · Score: 0

    Can't tell the difference between a joke and a troll.

  43. or by include($dysmas) · · Score: 1

    shoot them all, i hate managers