Software Development

A pragmatic approach to training programmers, part two


Last week's post about a pragmatic approach to training programmers has generated a lot of interest. This week, I will fill out the details of the second half of my proposed coursework.

Semester 5

C++ 2

As a follow up to last semester's C++ course, students will write two small C++ applications, and one larger C++ application, with hands-on mentoring from instructors and TAs.

Database Architecture Students will be taught in-depth database design and architecture, with a focus on the architecture's effect upon programming. The relationship between normalization and how to write fast-performing SQL code depending upon the level of normalization will also be explored. CPU Fundamentals

In this course, students will learn the nitty-gritty details of CPU architecture, including the differences between CISC and RISC platforms, binary operations, memory management, and so on. Hands-on coding practice will occur in assembly language.

Development Methodologies

The differences between various development methodologies such as Waterfall, Agile, RAD, and so on will be taught. Students will participate in an ongoing series of workshops that mock up a development environment, alternating between playing the role of customer and developer.

Semester 6

Java This introductory course in Java will bring them to a level of fluency. Students will learn the Java language, details of the JVM, and the relationship between Java and J2EE application servers. VB.Net

Students will learn VB.Net, as well as the .Net Framework and the ASP.Net system. There will be significant focus upon event-driven application programming.

C#

Students will be taught the C# language, as well as many of its advanced features such as anonymous functions, lambda calculus, and so on.

Security

An intensive course covering the ins and outs of writing secure code. Students will learn about buffer overflows, data validation, SQL injection attacks, cross-site scripting attacks, and other typical security problems. Students will be asked to find the security holes in previous projects that they have worked on and to correct those holes as an exercise in hardening existing code.

Semester 7

UNIX Programming

Students will learn to program specifically on the UNIX platform. Special emphasis will be placed on the significant role of processes (including forking), pipes, sockets, and redirection. Students will also be given instruction and practice writing applications that deploy well in UNIX.

Windows Programming

Students will be taught how to program specifically for the Windows platform. Areas of focus will include UI design and the Windows API, and a heavy premium will be placed upon security.

"Lone Wolf" Programming

Students will be required to build a rather large project using a methodology of their choice. They will have to perform requirements gathering, specification writing, planning, development, and testing of their application.

QA

Quality Assurance (QA) techniques will be taught in this half-semester course. Students will learn about QA and perform load testing, unit testing, code reviews, and so on, and be expected to correct any problems that they discover. The code will be pre-built for them, to allow the students to focus on the QA process and not the code writing process.

Documentation

Students will learn how to properly document code and the various techniques available, as well as the best places and times to use different techniques. Inline code, reference generation, help file creation, manual writing, and such will all be covered. This is a half-semester course.

Semester 8

Team Programming This double-size course will have students working on four separate team projects. Students will function as developers in three of the projects, and as a business analyst/project manager/technical lead on the fourth project. Each project will take half of a semester, and each student will work on two concurrent projects. Multithreaded Development

In this advanced course, students will learn about parallel program design. Signalling, concurrency, and data integrity will all be taught. Students will be exposed to pthreads, the Java threading model, and the .Net threading model.

Semester 8 Electives

Each student must choose one of these courses as their final course in Semester 8:

Graphics

Students will learn to program window manipulation and graphics handling on the Windows platform using C++ and DirectX.

Device Drivers

Students will learn about writing device drivers and practice writing a simple driver using assembly language on a limited functionality UNIX platform.

Optimization and Refactoring

Students will examine code to find inefficiencies and refactor code to drive performance, ease maintenance, and reduce potential points of failure. The code will be pre-written to allow students to concentrate on the lessons.

Scientific Programming

Students will practice the translation of scientific theory and mathematic algorithms into code, using the language of their choice on the UNIX platform.

Network Programming

This course will teach students how to code communications between computers using sockets. Students will be given practical advice and hands-on training in determining if reusing an existing protocol makes more sense than developing a new one, the choice between UDP and TCP, and there will be special emphasis on the HTTP protocol as well as the difference between applications running on LANs and WANs.

I hope you enjoyed this series. As always, feedback is welcome!

J.Ja

[Edited 7/30/2007 {Justin James} to add a missing period and paragraph break at the end of the first paragraph.]

About

Justin James is the Lead Architect for Conigent.

45 comments
ptrees
ptrees

A very well balanced course, I'd choose Graphics for my final. Thanks for an enjoyable read.

Tony Hopkinson
Tony Hopkinson

I think I'd try to build the team work thing in all the way through. Emphasise documentation step one which is maintainable therfore readable code. May be another elective, for non procedural languages as well. Other than that I can hear the MBA, once wrote a macro, types running away screaming now, so well worth the effort.

Justin James
Justin James

Or did I miss a great topic or two? Is this coursework too ambitious for a four year course, or not ambitious enough? Let me know! J.Ja

Justin James
Justin James

I really wish I had written a better intro in Part 1, about the overall methodology for the teaching itself, because I always thought of this as having a lot of teamwork throughout. But somehow I never actually talked about things like entrance requirements, teaching methods, and so on. I smell a Part 3 in my future... :) J.Ja

sconyers
sconyers

I enjoyed both parts. As a new graduate, I was comforted to see how many times my education matched up with your ideal one. :)

John.Julian
John.Julian

In interviewing candidates for positions, I see a lack of what I consider essential skills: 1) Systems and 2) "Engineering methods". By Systems I mean the ability to look at something and see the cause and effect of actions on the overall. The ability to see how everything fits together and affects other pieces. By "Engineering method", I mean that process of approaching a problem and being able to break it down into components, and continuing this process until the problem is managable. These two ideas go hand in hand. Being able to see the system is part of the engineering method. John Julian

.Sherwood
.Sherwood

Justin, Although this would create technically profecient programmers, they will have missed out on the value of a well rounded education. There needs to be economics, writing, mathematics, critical thinking (beyond logic), natural sciences, social sciences, foreign language, etc. included in any well rounded education. Otherwise you will end up with technically proficient coders who can't communicate with their business analysts because they have neither the skills or the background to understand what they are talking about. Programming skills can be covered with much fewer courses. The differences in most programming languages is just a matter of syntax. Opening ones eyes to a world of knowledge and ideas is much more valuable than just being trained for a specific job.

Wayne M.
Wayne M.

These don't warrent a class of their own, but should be covered somewhere. * Source Control Systems - Lock and Check Out vs. Merge and Check In. Ad hoc, zip directories and file naming. * Using Make and build dependencies.

Locrian_Lyric
Locrian_Lyric

...but upon reading both articles, I'm struck with the notion that such a course will end up building exactly what the market seams to fear the most, a jack of all trades. I guess the question I have is this: What is better, to create a kind of 'generic' programmer or a specialist in a particular discipline? Perhaps after this stage, advanced courses in tracked disciplines? Track 1: The Scripting track Track 2: The "C" family track Track 3: The MS family track Track 4: the interdisciplinary track (or the 'jack track'

oz penguin
oz penguin

Very ambitious. How about scripting: perl, sh, csh ksh, python ... I think it's going to be a 10 year course ;)

Wayne M.
Wayne M.

It might be useful to have the Methodology, Security, QA, and Documentation classes work with teams in the language classes. This might provide the best simulation of the real world and would cover giving and receiving evaluations of code products. I am not sure methodologies can be adequately explained using a textbook and directing a group of peers in a Waterfall or Agile development effort is about as sink or swim as you can get.

Tony Hopkinson
Tony Hopkinson

offerings are Other peoples code (or the numbwit with same name who's 6 months younger :D) Fault finding / debugging Finishing, what is a workable solution) Practical design (Trade offs) Performance Team work gives you a great set of examples for all of these things, which seeing as they don't do it probably explains why we have to teach their students so much when they get to us. It's when they come out with more letters after their name than I've got in mine. Then they ask you to help find a bug somewhere near the goto statement, you begin to feel really sorry for the poor boogers.

Justin James
Justin James

I would be itnerested in knowing where you received this kind of education. From what I can tell, the Chubb/DeVry type schools sort of appear to offer the same *idea*, but without having a courseload beyond "how to program in XYZ langugage", the same for community colleges. Thanks again! J.Ja

Tony Hopkinson
Tony Hopkinson

between teaching programming and teaching how to 'program' in a language. Far too often the language is seen as the skill, whereas it's merely a tool. A lot of it is cultivated natural talent. Someone who struggles to see a software system as a set of interconnected parts is always going to struggle with the job. No one taught me how to do it, it's just the way I think. What I learnt to do was apply it better.

Justin James
Justin James

I am 100% on agreement with you, but it seems like the bulk of the market today does not agree with us. :( Personally, I have enjoyed tremendours success in IT with my BA in liberal arts... due in large part to the "soft skills" that I picked up along the way. Sadly, when evaluated a potential hire, the majority of recruiters and hiring managers look solely at the "hard skills" (luckily I have those too). One piece of feedback I kept hearing in this space over the last year was that there really needs to be an intensive, hands-on, "vacational training" type of method to teach programming, with enough "real world" skills for the student to not be lost when they get to the workforce. Hopefully, that is what I have been able to lay out here. I also agree that a langugage (at least the syntax, for most langugages) can be learned in a matter of days of a novice and hours for an expert. That being said, how to *properly* use a language takes much longer. For example, staring at Perl for 30 minutes taught me enough to write it, except for the regex's. But I could not effectively use it... I had working, but lousy code. Java, VB.Net, C#, and C++ all have fairly simple syntax, but knowing their particular nuances means the diffierence between "working" and "good" code. More to the point, a potential employer wants to see those skills listed on a resume, so my coursework teaches them. At the expense of the general education, that we both agree is quite valuable. My experience has been, someone with a real drive towards programming can study anything they want in school, and still have the tech skills because they are willing and able to self teach. But the vast majority of people in the industry are not willing or able to do that, and most colleges do not offer good programs to teach real world capable people. J.Ja

Tony Hopkinson
Tony Hopkinson

JJ said he's going to do a part three about delivery of the material, if you'd have read the entire thread (and part 1) you'd know that was a big part of the idea. Development is not a specific job it's a specific skill, the so called well rounded bit should already be there from school. You wouldn't have time to learn hello world in javascript with your idea and would probably use javascript everywhere. If he wanted MBA's who once wrote a macro, he could leave academia alone, they turn them out just fine. What the heck is critical thinking (beyond logic), guessing ?

Tell It Like I See It
Tell It Like I See It

Another thing I'd like emphasized throughout the whole course is that people need to look at the big picture. All too often it seems that some programmers end up only concerned with their tiny piece of the system as it is needed today. They don't think about what will come up tomorrow, even when it costs very little to put certain hooks in place now. The result is that in six months to a year, they have to just about scrap their little piece to add new functionality that they didn't see coming.

Justin James
Justin James

Source control could be baked into those team work classes in the last semester, and make/build etc. I would assume would get covered during C++. But yes, great points! J.Ja

Justin James
Justin James

Richard - You are actually pretty correct, as far as the IT recruiters are concerned. But I also agree with what Tony says as well, in that the skill truly being taught here is "thinking like a programmer". I would love to add some "advanced" tracks, but I am not sure how long someone could legitimately be in training before their head explodes... look at the number of folks who get BA's vs. MA's. At the end of the day, I tried to think of all of the things I had to struggle with professionally to get to where I am at today, and what kind of course load contained the core knowledge and understanding and would have trimmed 5 years off of my learning curve. That being said, I am considered a "jack of all trades" (I've held the "big three" IT titles: sys admin, network engineer, and developer, and many of the "in between" titles like "webmaster"). But please, I prefer to not think that I followed the "jack track" (mainly because it just sounds wrong...). ;) J.Ja

Tony Hopkinson
Tony Hopkinson

One skill development. It's only ignorance that treats someone who can code in two languages as multi-skilled and total buffoonery to suggest that someone who worked in telecomms, has a differnt skill to one who worked in banking. I've never had a job in IT that could only be accomplished with one so called 'skill', don't want one either. Specialism is for insects Woodrow Wison Smith.

Justin James
Justin James

In Part 1, I had a dynamic/interpreted langugages course, to give exposure. Scripting is not what is used to be, unfortunately. There is little demand (currently) in the mainstream for it, *relatively* speaking. 10 years ago, Perl expereience was free money in the bank, but now it's all about the J2EE and .Net. Of course, in a few years, I will probably revisit this topic and see what needs to change! Personally, I love scripting langugages, but too many coders who use them (including myself on occassion) are abusive to them. J.Ja

Justin James
Justin James

I did not think of it at the time, but you are right that it is "sink or swim". Which fairly accurately sums up the careers of most programmers I know. :) In all seriousness, you are right, it may be a bit much, maybe have a TA/teacher act as the manager instead, for that big teamwork class at the end? J.Ja

Tony Hopkinson
Tony Hopkinson

But if you had one do the front end, one the data access and one the DB or a similar split The modules will get along as well as the students did... Doing a messaging app between unix and windows with XML content and a third person 'in charge' of that is another. Just get them thinking about how their bit fits in with the others and how the design of one end impacts the other. Come up with a phase two aand switch roles and teams. Stuff like this is way more valuable than stuffing in an extra bit of tech or methodology.

Wayne M.
Wayne M.

Catching up on my reading following vacation, I just ran across the following article describing the curriculum approach at Neumont University: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=297067 Basically, it is described as a project-based approach with classes running 8:00 - 4:00 every day. This sounds like an interesting approach for fulltime students, though it probably wouldn't work for any of us out in the workforce.

Justin James
Justin James

Wayne - I agree that a semester based approach does indeed pose a number of limitations... I would almost prefer to see a tree structure, with some branches occassionally "thicker" than others at times, some quite narrow on occassion, some branches rejoining later on, and some just completely dying off... similar to a Linux distro chart. ;) However, that is a very tricky formula to fine tune, and I think a lot of people who have a tough time grasping it in terms of understanding what would happen when. Also, it requires impeccable timing... an event as minor as one professor being out a week or two could throw the thing off by a year, depending upon when that professor fell on the "critical path". J.Ja

Tony Hopkinson
Tony Hopkinson

like one character variable names, side effects, misleading identifiers, there is no one standard for readability. I'd try to get across various tips for a achieving readability, such as in a team development coming up with a glossary of terms, a damn useful piece of documentation that's always so 'obvious' no one bothers with it. If you come across a piece of 'unreadable code' you need to look at why it is. It might be domain jargon for instance, very little you can do about that aside from become familiar with the domain.

Wayne M.
Wayne M.

ronn, I agree with most of your suggestions, but I think we would want to have at least an introduction to OO design concepts before having students code (or at least code in any OO languague). I will also strongly support Tony's recommendation for a Readability course (and grading based on readability for every coding course). I am guessing, though, it will take a very brave man to define the contents of a Readability course! We may be seeing some of the restrictions of a semester-based teaching system here. So many of these topics are really so inter-related that they need to occur in parallel and be continued throughout the coursework. It is difficult to get people to code correctly without knowing the basics, but it is hard to teach the basics without actually applying them in code.

Tony Hopkinson
Tony Hopkinson

It can be perfectly sound well designed code, and revision two done by an other person will cause problems. Putting bad coding techniques in to me gives the impression that dealing with other people's code is about fixing their technical mistakes. What you want them to learn is Writing readable code. That complexity is not desirable That coupling costs That there is a trade off between abstraction and functionality. That the 'interface' to a class or a library is a user interface. That documentation isn't for management. Code always looks not as good as it could be, otherwise us nerdy tech types would still be developing it. :D

Ron_007
Ron_007

Tony covered many of my points. Methodologies should be moved up to 1'st or 2'nd term, students should have opportunities to use various methodolgies Security- also move to 1st or 2nd. This is the single largest failure in teaching programmers. No one bothers to teach them the concepts, then everyone is upset when they repeat known errors. In a newly designed school curriculum secure programming should be emphasized early and often! QA & Documentation - these courses should also be early in the curriculum. Actually, most of what they need to know could easily be integrated into the other early programming courses. In school I was required to write my complete Pseudo code before starting any coding. I actually used it to provide many of the comments in my final code. And they should learn proper testing methodologies and techniques early on so that they can use them in their development. Actually, almost from the beginning, they could act as QA for each other. Code walk-through and test each other's programs. Lone Wolf & Team Programming - what would you cover in this type of course. Actually, I think the concepts could be introduced early and worked upon through the whole program. At my programming school "colaboration" was an automatic FAIL. The way I would design a curriculum would be to require lone wolf programming initially to encourage initial learning of basic concepts, then moving into team programming. One way to introduce them to the real world of team programming would be to give them existing programs to modify for their assignments. The programs could be part of a previous collection, or you could simply assign programs from their classmates. The programs would include bad coding techniques and even some functional errors. And for the individual class genius (who has been programming since he was 5 years old, I went to school with a couple of them!), give them programs with more errors for them to find for bonus points. I realize that this moves a lot more stuff to the front end, but you could move a few things later, ie "Networking & Sys Admin", "OO Design" could be pushed back a semester or two since they are not part of BASIC programming skills needs, they are slightly more advanced (OO) and peripheral (networking) areas. Somewhere in the program you could include some "soft" skills, ie psychology, HR since computer "geeks" are often not "people people". Computer / Program Archeology : I would like to see a short course, 1hr per week, on this topic. All to often, as programmers we look at something and think "WTF were they using for brains...". But if you know the history of the program and the corporate environment, many apparently dumb things can be explained away (not justified, but at least understood). For example, I worked at a company where we told new hires NOT to use the existing code as a model for new work. The lousy code actually was the result of a mechanical language translation program that did many incredibly stupid things. The system ran, but it was expensivley CPU inefficient. There were several simple alternative coding techniques that were used in new code. But if you didn't know why the code looked the way it did, and you knew anything about proper coding techniques in that language you would wonder what kind of idiots wrote the programs. (Of course we were not allowed to retrofit the known fixes, because of the "don't fix it if it ain't broke" mentality which ignored the idea that we were going broke (financially) constantly buying more CPU Cycles than we really needed. It was all part of a long sad story of a project from "heck" that went terribly bad). I hope existing schools out there hear about this blog and take notice.

Justin James
Justin James

Wayne - Absolutely true! It took me not too long to recall enough BASIC to catch on to VB.Net. I am *still* finding new items in the .Net Framework that keep me from reinventing the wheel. J.Ja

Wayne M.
Wayne M.

I will concur with J. Ja's comment that the syntax of a language can really be learned in a couple of hours. What is important in basic mastery of a language is learning the various key libraries associated with it, both standard and proprietary.

Wayne M.
Wayne M.

Rather than debate the issue here, I would just recommend that the Methodology course cover plusses and minuses of preplanning and hooks versus YAGNI (You Aren't Gonna Need It) and Evolutionary Design. As an aside, code that has to be completely rewritten to add a new feature probably exhibits poor structure and readability. That is a different issue than including or not including future needs.

Tony Hopkinson
Tony Hopkinson

First don't give / make the required information available to the developer for political reasons. There are those are against buolding for potential future change. Like you I'm not one of them. Just adding a dummy ancestor class in teh hierarchy, a property or a method stub can help enormously when the revision does come up. Especially if there are further chnages in between the forethought and the actuality. I do it when some business types says something like "oh no we'll never want to link to the invoicing system". Just about guarantees it's going to happen. I don't agree with writing code that you think might be required, designing with a potential future requirement in mind though is common sense though in my opininion. It's another thing that teaching with examples of what happens in the real world, will highlight.

Justin James
Justin James

... the more I think a Part 3 is needed to explain stuff like this, because I am in agreement with this, but it certainly is not explained in either post so far! J.Ja

lingga_cuex
lingga_cuex

need an example of network documentation...reply asap

SoftwareMaven
SoftwareMaven

I would actually move both of those up to the first half of the course, similar to the concepts with requirements, and have them be required in every course. There is a reason that every Agile method are strongly test-oriented. The sooner that is taught and the more it is repeated, the stronger the programmer will be. The age of thinking of "Programming" getting done and then "Testing" getting done really ought to be over. Programmers ought to be doing significant testing on their own and schools (especially vocational oriented) should be enforcing that from the beginning. Travis http://cmssphere.blogspot.com/

Justin James
Justin James

One thing to note, I tried to avoid the obsolescence issue as much as possble, by loading the langugage-specific stuff in the back where it can be swapped out and folks graduate with fresh skills. C/C++ will never die, so that is safe to put in there... and I took a risk by *suggesting* that the very first course be in Pascal, simply because its properties make it a superb teaching langugage. J.Ja

Tony Hopkinson
Tony Hopkinson

Programming / development / solution providing is the skill, the rest is tools and environment. Being able to write something out in VB does not make you a programmer. Any programmer should be able to pick up VB though.

Locrian_Lyric
Locrian_Lyric

When it was Unix/Windows/Mainframe C/VB/COBOL and SQL it WAS all one skill set. now there are so many languages and flavors of languages in addition to scripts, markup languages, that to get any meaningful depth in all of them would involve a full four year program with little or no electives. PLUS, by the time you graduated some of your skills would already be dated.

Tell It Like I See It
Tell It Like I See It

I still have times where non-technical users ask for certain folders to be backed up from their hard drive to the network. Is there one common parent folder? Either the answer is no -- or the answer is yes, BUT, they don't want all these other folders within the parent backed up. After the inward sigh, I ask them to send me an e-mail listing specifically which folders they want backed up and where they want them to be backed up to. DOS-style batch files work great for this. It's one of the reasons I hope MS never gets rid of them. Just put the batch file on their machine, give 'em an icon on the desktop for them to click and they are oh so happy. (Like I said -- non-technical.) One guy I knew a while back did some things with batch files that I was adamant couldn't be done -- until I saw him do it. His nickname / call-sign in the office was BAT-man. Unfortunately, I can't remember what it was he did (too long ago) but I was floored that mere batch files could handle it. Like I said, in the hands of a master, they're quick, easy and surprisingly powerful. I haven't had the opportunity to work with PowerShell yet, so I don't really know what it is like. However, I do admit I've heard plenty of good things about it.

Justin James
Justin James

I think DOS-style batch files are finally going out of style, with PowerShell, but I agree that they can still be useful. *Nix, of course, has had shell scripts forever (so does Windows, with horrid VBScript... ugh). I will say, the only person I ever saw make real use with a batch file is my father... he would do some wizardry to accomplish some amazing feats with TSRs and memory usage in DOS, still makes little sense to me thinking about it today. J.Ja

Justin James
Justin James

I am also a huge fan of Perl, but sadly, its mainstream appeal is quite on the decline. Unless Perl 6 revolutionizes the world, Perl will quickly fade back to its roots. To be honest, J2EE is fairly foul to me. Maybe it is just because everytime I try to look into it, I spend 3 hours reading about a dozen frameworks with meaningless names ("Struts", "Server Faces", etc.) and yet have no idea what they do! Or maybe it is the use of camel case in Java world (I really get irritated when I see camel case, for whatever odd reason), or it could just be the miserable experiences that I have had with Java in the past (used it in 2001 - 2002). If I am going to deal with a resource higging VM, I'll stick with .Net, personally. I think the framework is better, and better documented to boot. Again, 100% personal opinion. J.Ja

Tell It Like I See It
Tell It Like I See It

Be sure to include information about batch files in your dynamic/interpreted language class. They still work under Windows and for some things they are much better than trying to build an entire script in anything else. This is especially true when you really know their full capabilities.

oz penguin
oz penguin

Granted, J2EE and .Net are the popular choices at the moment, but on a UX platform I (personally) would chose perl 9 times out 10. J2EE is a true likely successor, but it is too memory hungry for me

Editor's Picks