- Agile/lean/iterative software development - any incremental process that emphasizes repeated cycles of development and feedback loops;
- Refactoring of existing code to improve design (per Martin Fowler's seminal work)
- Object Oriented Design Patterns as popularized by the "Gang of Four" - Gamma, Helm, Johnson, Vlissides
- Test Driven Development / continuous integration / acceptance testing
- Performance Testing - code profiling, metrics, etc.
- Agile Requirements Specifications - writing user stories, relative weight estimation, release planning, etc.
In the post, I set out to test a hypothesis that the majority of computer science schools in Ontario were not teaching these best practices, focusing instead on the "worst practices" that are contributing to the industry's significant problem in meeting targets like cost, scope, schedule and satisfaction - something I collectively refer to as "BDUF/waterfall" or "Big Design Up Front / waterfall" processes, which define the prevailing view of how software should be developed.
I tested the hypothesis by performing a rough comparative analysis of the course calendars from each school - in much the same way a prospective student might when shopping around for a school to attend. Unsurprisingly, I found my hypothesis held true with only four Ontario schools out of sixteen teaching best practices courses.
A Review of Canadian CompSci Schools
Naturally, I wanted to extend this analysis to the rest of Canada, so I set about gathering and sifting through twenty-five course calendars for schools from the Pacific to the Atlantic. Below is the summary of my findings (click to enlarge). As with the previous review, my raw research notes can be found via a shared Google Notebook I've created.
As with the previous iteration, this table illustrates three significant points of comparison between the schools:
- Does the CS department offer a course exclusively in the best practice(s) ?
- Does the CS department offer a course that teaches a best practice as a constituent component of a course ?
- How many "software engineering" vs. "best practices" courses are required for a degree (H.BSc.)
With respect to the first point, cells are highlighted in orange, with contiguous "blocks" aggregated together with a border to indicate multiple practices that are taught in a single course - there are some clarifications for certain schools that I'll explain below. With respect to the second point, cells are highlighted in blue.
I've also added two new comparison columns to break down the summaries: Object Oriented Design / UML, to indicate those courses that are definitive in the discipline, and Requirements Engineering to highlight this "bad practice", which I previously assimilated as part of BDUF/waterfall.
Highlights
As with the Ontario analysis, best practices aren't a uniform part of computer science curriculums across Canada:
- Of all practices, Object Oriented Development and Design Patterns make up the bulk of topic offerings for almost half the departments analyzed;
- Agile/lean/iterative practices are still in the minority, being offered by only six schools (U of Alberta, U of Calgary, U of Manitoba, McGill, Memorial University and Saint Francis Xavier), three of which are in a dedicated course offering (U of Alberta, U of Calgary and U of Manitoba), and of these only two (2) or 8% are degree requirements (Alberta and Manitoba);
- Refactoring is only offered by four schools (U of Alberta, U of Saskatchewan, U of Manitoba and McGill), three of which make it a part of a dedicated best practice course. Of these schools, only two (2) offer courses that are within degree requirements.
- Agile Requirements are pretty much unheard of, being offered only by two schools (U of Alberta and McGill), one of which is within core degree requirements.
- BDUF/Waterfall processes are overwhelmingly pervasive, comprising the majority of "software engineering" course offerings and degree requirements.
Exemplary Schools
As with Ontario, there are a few schools in Canada that stand out from the miasma with some top-notch offerings that others would do well to emulate - if you or someone you know is interested in taking Computer Science, these are schools to include in your shortlist:
University of Alberta @ Edmonton
- CMPUT 301 Introduction to Software Engineering: This course is a clear winner that rivals its Ontario competition if only because the modules are targeted at 5/6 best practices backed up by recognizable industry names. I was immediately impressed that the work of Mike Cohn on agile requirements gathering was specifically mentioned. Only criticism: No TDD - but that's minor considering how much else is in the curriculum.
- CMPUT 201 Practical Programming Methodology: This course caught my attention because it takes a pragmatic approach to imparting professional skills to students. One quote in particular blew me away: "Like the best carpenters and artists, the best programmers combine both a solid theoretical foundation with "best practices" and tools refined by years of experience... CMPUT 201 is a "doing art" and not an "art appreciation" course; it requires hands-on, active learning. For a programmer, the end product is a complete, working program."
A definite winner, even though the course substance isn't totally within the realm of what I define as best practices.
University of Calgary
- Software Engineering 515 Agile Software Engineering: While there wasn't a more detailed course outline, this non-required course stands out as a unique, dedicated offering. Unfortunately, the prevailing thinking in the department is definitely biased toward BDUF/waterfall, as evidenced by the remaining courses.
University of Manitoba
- COMP 3350 Software Engineering: This degree core requirement course offering is on-par with Alberta's CMPUT 301, covering test driven development, refactoring, design patterns and a gentle introduction to "appropriate agile processes" for a team project. The textbook, Sustainable Software Development - An Agile Perspective by Kevin Tate is worth having on the bookshelf and hits all the right notes.
I really liked how this course tied in TDD - even if it is missing the agile requirements gathering that Alberta's course has.
- Unfortunately, all the good of COMP 3350 may be totally undone by COMP 4050 Project Management which emphasizes a litany of worst practices, including project definition using PERT, Gantt charts and critical path analysis. I say unfortunate because 4050 is also a core required course for the software engineering stream.
McGill - Quebec
- COMP 303 Software Development: The sole exemplary offering from La Belle Province of best practices follows the formula set by U of Alberta, U of Calgary and U of Manitoba with this required course for CompSci/Software Engineers. Design patterns, refactoring, unit testing and design-by-contract and top-notch OOD practices (eg. separation of concerns) are all covered. While the required text is Java-biased, it does cover design patterns and using the JUnit unit test suite.
- COMP 304B Object Oriented Design: While not a required course, this should be taken in conjunction with COMP 303 as it focuses exclusively on OO design fundamentals, including Gang of Four design patterns, which incidentally, is also a required text for the course. Unit testing with Python is also done - a little weird, but it's good to stretch the mind beyond the C/C++/Java curly-brace languages.
- COMP 335 Software Engineering Methods: Another course that teaches an agile/incremental process for guiding software projects - this one focusing on eXtreme Programming along with unit testing, teamwork and project scoping. The required text isn't that great, but hopefully the profs can relate the material well enough to avoid relying on it. Again, since this isn't a required course, it would be good to take along with the two previously mentioned courses to limit the damage done by other BDUF/waterfall offerings.
Honourable Mentions
University of British Columbia
- CMPT 275-4 Software Engineering: Covers unit testing and OO analysis, which unfortunately get mired in some BDUF/waterfall practices. It earns an Honourable Mention because of the texts in its recommended book list: The Mythical Man Month by Fred P. Brooks, Professional Software Development and Code Complete by Steve McConnell. While I disagree with Steve on a lot of points, he's a recognized name in the industry that students should be aware of - and Fred Brooks? Obviously.
- CMPT 475-3 Software Engineering II: Designed to pick up where 275-4 left off, this one I mention again because the course text gives me hope that the course isn't as bad as I think it is: Facts and Fallacies of Software Engineering, by Robert L. Glass.
Bishop's University - Quebec
- CSC328 - Object-oriented Software Construction: This course has a lot of potential from the outline to expand to cover a lot of best practices. In its current incarnation only design patterns and UML are covered, but it does so through coding in four OO languages: C++, Smalltalk, Eiffel and Java. Of these, Smalltalk and Eiffel have a long pedigree of spawning best practices like test driven development, refactoring, etc.
Memorial University - Newfoundland & Labrador
- COMP 3716 Software Methodology: Covers iterative software development with an eye toward comparing it critically with traditional BDUF/waterfall processes - this is rather unique across the board - alongside design patterns and UML. The course text isn't the best, but the author, Craig Larman, is a recognized name in the industry in pro-agile circles.
- COMP 3718 Programming in the Small: This course stuck out to me from its title as it implied an attention to detail - and that pretty much sums it up. Backed by Brian Kernighan and Rob Pike's book, The Practice of Programming, this course looks to impart some fundamental skills. Not so much "best practice" as de facto rules of thumb that contribute to professionalism. Should be a required course!
Acadia University - Nova Scotia
- COMP 3783 Advanced Object Oriented Application Development with Smalltalk: Smalltalk didn't win the war of OOD language supremacy - that went to Java and C# - however, a great deal of work in best practices was done using Smalltalk, and for that reason I recommend this course over the identical offering COMP 3773 which focuses on C++ and is required.
Personal Software Process
A few schools in my analysis have been promoting Watts Humphrey's PSP as part of their software engineering stream. Far from being about personal development as a developer or a better way to manage small projects, PSS is a forerunner component to Team Software Process and the Capability Maturity Model (CMM), each of which emphasize the notion of coercing agile tenets within a heavy process framework. I recommend avoiding any PSP offering as its adoption is near zero in the industry and is predicated on the notion of increased up-front planning yielding a better product without a customer feedback loop.
Conclusions
Across both the Ontario and Canadian school analyses, while a complete offering of best practices is still not supported by the majority of computer science departments, the ones that do are leading the way with some top-notch efforts which go a significant way toward putting the lie to the naysayers who often trumpet that these efforts "can't be done" and "don't believe" in their worth.
Unfortunately, the majority view of BDUF/waterfall practices continues to hold sway and degree required courses vary wildly without consistency, rhyme or reason: Some departments require six software engineering courses, others two and still yet others none. In terms of best practice courses, the number drops dramatically with the norm being zero.
As with the Ontario analysis, there are a myriad of potential reasons for these discrepancies which can be attributed to each school setting their own curriculum. While this is their prerogative, it's unfortunate that there isn't even an accepted baseline to work against that promotes best practices.
Additionally, the same discrepancy between "computer science" and "software engineering" stratifies who's required to learn best practices - and this doesn't help graduates at all.
In sum, there's still more work to be done to promote best practices that can be affected by business (who can demand it from schools) and by students themselves to pressure their departments to improve their offerings. I've listed four schools who can serve as a starting point - I'd love to see four more join the list in four years!
Let me know your thoughts and observations.
 I'm still working on compiling results for the cross-Canada conclusion to my "Who's Teaching Best Practices?" posts from last week, however, in the meantime I wanted to relate a series of posts by Chad Fowler from late last year on a topic that I think dovetails with some of the themes I've been exploring - namely, that "software engineering" isn't what some believe it to be.
Chad writes about one of the most pernicious and common scenarios that developers face: The re-writing of an existing system in order to either migrate it toward a new platform/language/technology or to improve its current design while festooning it with new bells and whistles. This trap leads to several anti-patterns that Chad relates:
-
Software as spec.
- Invention or implementation?
- The wish list.
- The "Big Bang".
- Justification and lies.
- Who's tending the store?
If you've been in software for more than a couple of years, you probably know the pain of at least half of these scenarios - most of which are made all the more painful through the "software engineering" of your predecessors. In my own experience, I've been involved in a number of large-scale re-writes and provided migration advice on others where I had domain knowledge. In all instances, the project took longer than projected, cost more and was the source of more agony than joy. In one case, the In one case, the project was resoundingly rejected by the client as excessively expensive (another tragedy of BDUF/waterfall).
 If you're new to the industry, and haven't already read Chad's blog, take a look at his brief list of anti-patterns: This will be in your future. For the old hands, read it and have a few wry, knowing chuckles between sobs.
Update: I've amended my observations under point #2 below to take into consideration some feedback I've been receiving.
Since releasing the results for Ontario in my previous post, I've been applying the same methodology to the remaining universities in Canada. Working from west to east, I've just finished with Quebec, and have the Atlantic provinces to finish up with today.
In the interim, I wanted to post some observations from my rough research so far that I found interesting, and in some cases indicative of what is thought of as "best practices" in CS departments.
1) Requirements Engineering
A number of departments offer courses in "requirements engineering" which in every case equates to "worst practices" as they instill the false conviction that the software development practice is improved if we push more effort into precisely specifying and freezing system requirements up-front.
Oftentimes you might hear that people want to “freeze” requirements... You can't freeze requirements any more than you can freeze markets, competition, learning, evolution, or growth. And even if you tried, you'd almost certainly freeze the wrong ones.
If all you do is take [your customer's]... initial requirements and implement them, you will certainly not be anywhere close to satisfying their requirements by the time of delivery -- the requirements will have changed. You're exposing yourself to one of the biggest risks in software development: you've produced what they asked for, not what they've come to want. The result? Surprise, shock, and disappointment instead of satisfaction.
2) Computer Science vs. Software Engineering
As I sorted through all of the calendars to piece together their programs and requirements, I noticed a curious pattern where some schools made a distinction between a degree in computer science with no specialization and one that focuses on software engineering. The difference between the two fell squarely on whether any "best practices" courses were required, and even then the requirements for "software engineers" varied wildly from one best practice course to four!
This struck me as quite short-sighted: In effect, it was entirely possible to get a graduate who could develop AI systems, write a compiler and analyze complex algorithms yet be completely dysfunctional in a software development team - all due to whether they took "Computer Science" or "Software Engineering".
This distinction is damaging, as it leads to some misconceptions about how software is developed, ie. that it is possible to "engineer" software as much as it is any physical object or machine. In 2005 I wrote about this disconnect under a post called That Damned Construction Analogy. At the time, I referenced Martin Fowler's essay, The New Methodology where he states:
In software all the effort is design, and thus requires creative and talented people. Creative processes are not easily planned, and so predictability may well be an impossible target.
In my opinion, when it comes to best practices there should be no distinction between "Computer Science" and "Software Engineering"; in fact, I'd go a step further and remove the distinction entirely as the notion of "engineering" software has very little to do, as Fowler observes, with how software is actually constructed.
3) Those that do teach best practices, do it well
Overall, the departments that have gone out of their way to create courses that focus exclusively on a particular best practice or basket of practices appear to do it really well. From content to labs to textbooks, it's a course worth taking - and unfortunately, isn't usually a required one.
Some examples include:
McMaster's SFWR ENG 3S03 Software Testing and Management;
Ryerson's CPS 845 - ExtremeProgramming and Agile Processes;
Queen's CISC 327 - Software Quality Assurance;
University of Toronto's CSC 207H1 Software Design and CSC 301H1 Introduction to Software Engineering;
York University's CSE 3311 Software Design and CSE 4313 Software Engineering Testing.
There are even more and better examples from other schools in Canada that I'll review in when I release the results of my expanded analysis next week.
4) Most online course calendars are abysmal
In the interests of "dogfooding", I think a lot of schools would benefit from having their students evaluate their department's website and building a new one. In almost every instance they are extremely frustrating and laborious to use: A perfect example of what "software engineering" is doing to the industry!
A final thanks:
I see that Mike Gunderloy published a link to my post on his blog, Larkware.com - and that's put it in front of a good number of eyes. Thanks for that, Mike!
Also, thanks to all who have contacted me about the article - it's great to get feedback on it and hear other opinions and observations.
Next Week: The results from my Cross-Canada "Who's Teaching Best Practices?" CompSci School Review
Update: I've revised the results table to highlight the best practices that are offered as an exclusive course and as a potential constituent unit, with the former in orange and the latter in blue. Additionally, I've adjusted the totals for each best practice column to reflect the differences.
Update 2: Dr. Gregory Wilson, Adjunct Professor of Computer Science at the University of Toronto recently contacted me to point out that they have a specific course offering in agile best practices (CSC301). While I do observe this in my table of results and raw research notes, I didn't make it clear in the bulleted highlights. CSC301 is exemplary in that it not only instructs on agile, but also design patterns AND refactoring in addition to other topics.
Update 3: I've released my findings for CS schools across Canada here.
A sad fact of the software industry today is that almost every IT project initiated will fail in one way or another. Delivery schedules will be blown, budgets exceeded, customers frustrated and developers burned out. The combined costs of these failures are estimated in the billions of dollars, and in some cases lives risked and lost.
Indeed, it's been well-understood for decades what factors contribute to project failure, and many astute minds have made significant advances on the matter from Fred P. Brooks to Martin Fowler, Robert C. Martin, Ron Jeffries, Kent Beck, Ken Schwaber, Jeff Sutherland, Mary Poppendieck and more. They have all contributed to a body of work that is collectively referred to as "best practices" that help steer projects away from the rocky shoals of failure as best as possible.
The obvious question arises: "Why are failures so high, when there's been so much work done to help avoid them?" While the answer is definitely a combination of factors, I decided to test a hypothesis that computer science departments are failing to teach "best practices", resulting in legions of graduates who are armed with antiquated or theoretical knowledge that help perpetuate the cycle of project failure.
The Methodology:
In order to test my hypothesis, I decided to do a comparative analysis of the computer science programs offered by the sixteen major universities in Ontario. Specifically, I wanted to look at their course calendars to see how many offered instruction in best practices and if it was possible to earn a degree without exposure to any best practices.
Best Practices Defined:
For the purposes of my investigation, I focused on six areas of discipline for best practices based on my own experience and generally agreed upon in the industry:
-
Agile / Lean / Iterative software development - any form of incremental process that emphasizes repeated cycles of development and feedback loops;
-
Refactoring of code to improve design (per Martin Fowler);
-
Design Patterns as popularized by the Gang of Four (Gamma, Helm, Johnson, Vlissides) or others;
-
Test Driven Development (unit testing), Continuous Integration, Acceptance Testing;
-
Performance testing through code profiling, metrics and load tests;
-
Agile requirements specifications - ie. writing user stories, relative weight estimation, task breakdowns, etc.
In addition, I wanted to know about courses offered that did not fit the above criteria, which I defined as Big Design Up Front / Waterfall "bad practices". Often these fall under the rubric of "software engineering".
The Results:
Below is a table that I constructed from the raw data I was able to glean from each university's online course calendar for the current 2007-08 academic year. At a very high level, I wanted to answer the question of whether the topics were covered, and have indicated with "Y" and "N" if the outline specifically mentioned the best practice in question. Those departments that offered instruction exclusively on a given practice (as opposed to a constituent unit) are highlighted in orange.
The last two columns in the table indicate how many "software engineering" vs. best practices courses are required to obtain a computer science degree.
Highlights:
-
Of the sixteen schools, less than one third offer any instruction in best practices with McMaster, Ryerson, University of Toronto and York alone offering exclusive instruction in agile software development practices;
-
While it is possible to earn a computer science degree at three institutions without exposure to any "software engineering" instruction (Laurentian, Ottawa and Western), less than one third require best practices instruction for their degree programs (McMaster, Queen's, Ryerson, Toronto and York)
-
Courses in "software engineering" at all schools overwhelmingly emphasize BDUF/waterfall/phased "worst practices";
-
No school offers a full compliment of best practices courses as either electives or degree requirements.
Perhaps most surprising in the findings was that the University of Waterloo offered no best practices courses. This is surprising given Waterloo's vaunted status as the go-to school for IT/software and happy hunting ground for Microsoft.
Conclusions:
Based on this very rough assessment, it seems that post secondary schools in Ontario are failing to impart recognized industry best practices to their students. I imagine that similar findings can be gleaned from other provinces and perhaps most U.S. schools - I hope to expand this research in the days ahead.
The net effect is that students are paying for knowledge that is a serious detriment to their profession and industry, and that a lot of post-graduate effort needs to be expended by employers (unlikely) and the students themselves (more likely) to become aware of and proficient with industry best practices - to go, as Andrew Hunt and David Thomas observe, from journeyman to master.
Unfortunately, as long as there is no demand from business to have better, more professional graduates who are skilled in these recognized best practices, software failures will continue to pile up, while those of us who are still in the game become increasingly cynical about an industry that seems indifferent to success.
It's time for a change, n'est-ce pas?
 This past Labour Day I took a trip to my local chain bookstore to pass an afternoon, get a cup of wonderful Starbucks and see what's new on the shelves. As a reformed computer text junkie who once had a floor-to-ceiling collection of O'Reilly, Wrox and Microsoft Press books, I have to admit it's a bit of a voyeuristic thrill.
I was perusing the software development racks when my eyes alighted on three books side-by-side that I thought neatly illustrated the differences between best practices and worst practices. Here are the texts in the order I found them:
Let's review these in turn, with the caveat that I only skimmed these texts for about 10 minutes each - which, in my experience is plenty of time to get the gist of the book as intended by the author.
Practical Software Estimation
It's beyond me how this book saw the light of day in 2007 when it's thinking is firmly rooted in the dark ages of software planning and estimation. In brief, this book's thesis revolves around the Function Point Method of information systems estimation that Alan Albrecht developed for IBM in 1979. It presumes, in good BDUF fashion, that to provide practical software cost/time estimates, we only need to know, up-front, all the functions that will go into the system.
Besides the fact that this is sheer fantasy, the clincher that this book should be relegated to the dustbin was a diagram where the famous "phases" of software development were laid out as the "ideal software delivery model" - ie. BDUF through to testing at the end.
Suffice to say, if you pick this book up and become swayed by the poppycock about how the methods are used at InfoSys and decide that it's how your next project will be run, well, you'll get what you paid for - which ain't much.
SCORE: 0/5
Continuous Integration
CI is, sadly, still an emerging best practice in the industry that throws a spanner in the works for BDUF adherents because it is predicated upon the heretical belief that systems should be continually integrated, compiled and tested. At least once a day. Whenever anyone checks in code. Automatically.
The lads who put this text together have some experience working with best of breed tools to make CI happen, ie SubVersion, JUnit and CruiseControl. Now, if your team is using different tools, you may need to do as the Marines and improvise, adapt and overcome!
All this said, they do provide a lot of practical information and snippets on how to set up a CI solution and have it up and running quickly. It's a practical guide for pragmatic developers. Semper fi!
SCORE: 4/5
Effective Prototyping for Software Makers
This is a book that every software professional should have on their shelf, in my opinion (yes, I'm getting a copy!) because it espouses the very important principle that in software development, design matters. This idea was impressed on me many times by a colleague at imason whose discipline was focused on usability, and has stayed with me because of the conceptual simpatico with agile/lean practices.
This text presents a very accessible way to model software applications using rapid prototypes that end users interact with early and frequently throughout the development process to keep refining the product. To what end? Why, a happy customer/end-user of course!
I was intrigued at the variety of strategies that the authors described, from traditional wireframes to mock-ups using Excel to the controversial Wizard of Oz mock-up where humans simulate how a system might behave once realized. All combined, they show how better systems can be developed through prototypes that help bring the actual system closer into line with customer expectations - a radical concept in the industry!
Ultimately, I believe Effective Prototyping is a must-have book because it "break the blinders" that have constrained developers into believing that they are engaged in a manufacturing discipline and not new product development. Once this distinction is made, however, there's no going back - so be sure that you want to "unplug from the Matrix" before reading this book!
Be sure to check out the book website for more info on Effective Prototyping and sample chapters.
SCORE: 4/5
|