Tips For Software Developers on Seeking Help and/or Reporting Problems with Code They are Writing

Throughout courses I have taught, students have asked for help because some code they are writing isn't working, or they have received error messages (Java, Umple, shell scripts, etc.) that they don't understand.

Throughout any software developer's career they will encounter coding problems and need to either seek help or report problems with technology they are re-using. They might be reporting a bug in a code library their company uses, or seeking help on Stack Overflow. The principles are the same when they are when reporting problems or asking for help from a technical mentor, Stack Overflow, a TA or professor in a course.

Too often, beginners don't bother to report problems or don't do so in an effective way. I have distilled the following from dealing with way to many incomplete, unhelpful, or unneeded reports or help requests.

Things to do when you have a coding problem and feel you need help or think it might be a bug:

1. Boil the problem down to the smallest case that still has the issue. So if you have 200 lines of code with an issue, subtract  parts of the code bit by bit until the problem disappears, then add the last bit back. Keep trying to subtract other bits. See if you can submit a question or issue just related to perhaps 5 lines of code, or the smallest reasonable number that manifests the probem. To determine the bits to subtract, focus on just the changes you have made to the previous working version of the code by doing a 'diff' with the previous version.

2. Try hard to ensure you cannot solve the problem yourself first. For coding problems, clean up the remaining code after step 1 code so it is nicely indented. Check for balanced brackets and quotes. Add some comments to it (this can help you understand it and often solve your own problems). Make sure you are using the latest version of the technology (the problem may have been fixed very recently -- maybe even in the last days -- so update to the latest possible version). Check on Stack Overflow or other places in case others have asked the same problem (e.g. in the chat tool your group or company uses). Search the relevant parts of the user manual (usually online) to see if you have misunderstood something.

3. If at this point it is a defect or failure you want to report, then look in the bug-reporting system to see if it has already been reported. A Google search for <technology> bugs will normally take you to the relevant system. And a Google search for <technology> bug <description of bug> will often locate other reports. If you find another report, you might find help for working around the problem, or you might be able to add additional information that will help developers. If you don't find a report, then you can add your own issue report. Give it a very descriptive and precise title and a good initial paragraph describing the issue.

4. Submit actual code that you are having problem with, rather than (just) a screen shot. Actual code that can be copied and pasted allows the person helping you, or the person reproducing the problem to very quickly run it themselves. Eyeballing the problem on a screenshot might not be enough: Sometimes the root of the problem is somewhere else in the code, or it is a problem with 'invisible' characters. And you cannot expect the person who has the problem to type in your code. You can also send a screenshot if it somehow sheds additional light on the problem (e.g. shows the error in context), but the actual code is critical. If you are sending error messages that refer to a line of code, make sure the lines numbers are visible in any screenshots.

5. If the problem involves a user interface, send at least one screenshot of that. Remember that usability difficulties are legitimate problems to be reported, or to seek help about.

6. If the problem is on the web, check if it occurs in at least 3 browsers (Chrome, Firefox, Edge, Safari, Opera), and report any differences. It maybe a browser incompatibility.

7. Make sure you carefully describe relevant aspects of your setup: Operating system and version, programming language or library version installed (e.g. result of java --version), browser version(s), IDE used, environment variables set.

8. Describe any inputs or steps that need to be done to reproduce the problem. This includes command line arguments, compilation steps, etc.

9. If it is not obviously an error you are reporting or asking about (e.g. if it is something you are trying to achieve), then describe in sufficient detail what you expect to happen or are trying to make happen,


Above all! Report. Don't just let problems lie there. Be proactive in reporting problems. It is your professional responsibility. So many times I have heard reports like, "All 100 of us had that problem, and we spent ages trying to work around it". The problem may have had a 10-minute fix and the developers may be very greatful to get the report.

Career slowdown due to childcare is a human rights issue for academics and other professionals

This morning,the Globe and Mail has an article about a report from the Canadian Council of Academies discussing the difficulties female faculty members have advancing their careers.

In general, the process of academic advancement does not mesh well with raising families, whether you are a female or a male.

In order to achieve tenure and promotion, professors are supposed to continually build a publication track record. Taking a break, or 'slowing down', just doesn't work.

One can't properly take maternity or parental care and expect to advance. Indeed female colleagues of mine routinely work during their maternity leave. One even has had her nanny with her in her office looking after her young babies, just a few weeks after each child is born. Why is such leave often impractical: 1) You have to maintain supervision of graduate students; you can't just abandon PhD's in process; 2) You can't just abandon research programs you have carefully negotiated since you often have deliverables or expectations from research clients. 3) It often takes 12-30 months to get papers published in top conferences and journals; you have to keep that process moving, and attend the conferences when papers are accepted. 4) The process of hiring and getting new PhD students going can take 1-3 years; if you wait until you get back from a maternity or parental leave, you have a long gap again before you have a productive research team (and heaven-forbid that you might have another child on the way).

After any statutory or negotiated leaves in a baby's first year, you have a fixed number of courses to teach, so any slowdown while children are young inevitably is deducted from your time to do research and write publications. Slowing down 33% (e.g. from 60 hours a week to 40 hours a week) due to  family responsibilities, might mean reducing the research time from 30 hours a week to 10, a 75% cut. Hardly anyone realizes this consequence.

Interestingly, the Law Society of Upper Canada (Ontario), which had a progressive policy towards enabling female lawyers to take time of for childcare by helping cover their office expenses during their absence, is poised to drop that policy.

This problem, however, is not exclusively a female problem. It affects men too. It contributes to divorce when male academics (and lawyers or other professionals) are unable to take their share of the childcare and family workload. It leads to family-oriented men getting left behind in the career ladder, or simply deciding not to take opportunities that otherwise they would have done.

I have personally found that I have not been nearly as successful in research since having my three children. The sleepless nights and other family tasks have slowed me down very considerably. I know this is the case for other male colleagues. PhD students can be particularly badly affected. I was lucky to have made it to full professor just at the time my first child was born. I believe I might never have made tenure even if I had had children earlier. It must be so much harder for women who have a greater biological imperative to slow down their career.

Institutions and society must recognize this issue, especially now that women make up the majority of students in most academic disciplines. I have seen too many women professors just leave because of this issue, or decide not to take on higher-level responsibilities. And my graduate students both male and female, that have had children, inevitably have huge drop-offs in research performance.

It must become a violation of human rights to not consider childcare and family in promotion, and to not as an institution or profession have active programs in place to accommodate employees and members while their children are young.

Universities and granting agencies, for example, should explicitly have policies that expect and account for 60%+ drops in research productivity when people have young children. Co-supervision of graduate students should be the norm for essentially all graduate students. And when I talk about young children, I don't just mean babies and toddlers; the productivity effect of caring for family may slowly drop off, but it doesn't really ever drop to zero, and should continue to be accounted for until children are capable of travelling by themselves to activities and looking after themselves at home when required.

Stop wasting researchers' time: Drastically simplify grant selection

Today, someone sent me this excellent blog post by UBC mathematics professor N. Ghoussoub discussing the immense waste of valuable time professors spend on applying for grants with a low acceptance rate. 


I have made the conscious decision to not even bother applying to grants with low acceptance rates. Even though I think my research is quite respectable, and I have over the years received a decent number of grants, simple economics tells me that it would be better to invest my time in doing actual research. 


What is the solution? Clearly professors need grants to hire graduate student, buy equipment and travel to conferences. Junior professors also need prestigious grants to boost their career. However, application processes for all grants should be streamlined.


There are excellent moves in this direction underway. The Canadian Common CV system will soon be in use by most granting agencies. Hopefully that will eliminate the need for researchers to spend any time in grant applications talking about their past research. Grant applications, at least for established researchers, should be primarily based on the CV (papers published, graduate students trained,. etc.). 


Let's take this three steps further:

• There should be a 'common research proposal system'. A researcher would write a set of description in a standard format for pieces of research they want to accomplish -- a maximum of 2-3 pages each, with a maximum of one page devoted to literature review, and few or no budget details. The proposals would be open to public scrutiny and comment. A proposal could be as focused as presenting a specific experiment the researcher wishes to conduct, or could outline a general set of research objectives, with their rationale. Proposals could be enhanced or removed as time goes by. The professor might actually finish some units of work, or might improve their ideas, for example.
• The common-CV system should be enhanced to automatically tag each publication with data regarding citations. It should also compute indexes like the H-Index (excluding self-citations), G-Index, and variants of these that weight more recent work more highly.
• Have a common simplified grant-application system. A researcher would select the grants they want to apply for, indicate which of their research proposals they would like to work on with each applied-for grant, and the amount of time they would want to spend on each task. Except for expensive equipment that requires quotes, the budget would simply indicate the number of masters, PhD and postdoctoral students, plus technical and administrative assistants that would be needed. The system would compute the budget based on standard salary rates plus an allowance for conference travel and basic equipment and supplies per researcher (the amount for these would be standardized for each field). This point about budget is important: In current application processes, professors have to write detailed budgets, but then almost never get the amount of funds matching the budget; the current process just forces professors to write essentially-fictitious budgets.

The above would drastically shorten the time a professor wastes applying for grants they have a low probability of receiving. Professors would essentially make 'standing offers' or 'standing requests' to do certain research.


Much of the computation of criteria for grant selection should be automated: Selection committees would give high weight in their decisions to data such as the citation indexes mentioned above, and versions of the citation indexes computed for for publications relevant to the research field of the grant. They would factor in trends regarding graduate student training, and the professor's available time (a professor with many other grants would have less available time).


For established researchers, the peer review process would be limited to two things: 1) Brief comments on the extent to which the researcher is continuing on an established line of research, and 2) suggestions regarding how the research could be improved. If a professor is branching out in a new direction, or is a new researcher, then more detailed comments would be needed. But for researchers that are continuing in the same broad line of research, the track record should largely speak for itself. The suggestions for improvements should primarily be to help guide the researcher.


With the above systems in place, the overhead of applying for and peer-reviewing grants could be drastically reduced.


Some would argue that citation indexes can be faulty. So can peer reviews. There would clearly be different biases in the above system, but I think there would be no major sources of unfairness introduced. The system would simply render the research process a whole lot more productive.


Ghoussoub's comments  about waste of research resources also can be applied to conferences and journals with low acceptance rates. For those, however, the solution is completely different: Simply increase acceptance rates so they are generally at least in the 40% range. Far too many decent papers are rejected in my field because of arbitrarily-imposed low acceptance rates.

Top degrees: Computer Science PhD and Software Engineering Bachelors

An analysis by the thebestdegrees.org website presents interesting data that should encourage high-school students to enter the computing profession.

They rank PhD in Computer Science as the second-best degree, and Bachelors in Software Engineering as the third-best degree. Bachelors in Computer Science is not far behind at 7th.

Their criteria combine job demand and salary, and are based on data from the US Bureau of Labor Statistics. This is not the only study to come to similar conclusions; every year fresh studies say the same thing. For example CareerCast rated software engineering the top career earlier this year, and another study used BLS data to draw interesting charts showing that software engineering is expected to dominate new job creation among all technology jobs.

I always tell people that software engineering and computer science degrees are among the few that essentially guarantee good jobs in the student's field of study. Note that most computer scientists end up practicing software engineering when they are actually hired (for my discussion of the differences, written a decade ago but still valid, see here) and I consider a CS graduate in an SE job to be, broadly speaking, practicing 'in their discipline'. Students who obtain most other degree types have a much higher chance of having to settle for a career outside the discipline of their degree. This includes degrees in the ever-popular biosciences or social sciences.

However a decade after the famous supposed tech-crash, a lot of members of the public remain incredulous when I tell them the above. They still have in their mind the total fallacy that computing is a field with high unemployment, largely because they have heard media reports of layoffs at prominent companies. But other hiring companies abound and there have been huge numbers of high-tech startups in many areas of the world.

At the University of Ottawa, where I am a professor, our first-year enrolments in these fields have only just this year begun to approach the levels of the mid-to-late 1990's, after being dramatically down for 7-8 years. Enrolments are still well behind their tech-boom peak of a decade ago. Meanwhile we are bombarded by companies desperately trying to hire people, but unable to find them. Co-op students complain of having too many interviews (which takes too much time away from their studies). By their fourth year, many of our top software engineering students have found jobs in at companies like Google, Adobe and Oracle at their head offices in the US – sucking fresh talent out of the local Ottawa market. A quick plug: UOttawa pioneered software engineering education in Canada and internationally; when our students go to these companies they report that colleagues from very prestigious US universities admire their abilities.

My message is this (and it is a message I have been telling people for 10 years): Tell anyone you know who is in high school or has kids of that age, and who has any interest in technology, to go into software engineering or computer science. There never was a crash of employment in the field, just minor blips that have long since passed. There are plenty of jobs as the above links show. In my own city, here are some links from job-posting aggregator Jooble to companies hiring now using 'software' and 'computer programmer' keywords.

As for doing your PhD in Computer Science (second-top job). I am glad to be one of those people! It is overall a great career. And most of my PhD graduates are doing well. However, new PhD's in Computer Science shouldn't count on becoming a professor any time soon, there are very few openings precisely because of the lack of undergraduate students over the last decade. This will hopeful rectify itself over the next decade, but consistent undergraduate enrolment increases are needed first. One of my five PhD graduates is a professor; two are independent consultants and two are working for high-tech startups. The challenge for those who are not actually professors is to maintain their research skills and publication record while waiting for the faculty-position job market to loosen up a bit.

Steve Jobs: A Personal Inspiration

Here's are my personal thoughts about what Steve Jobs has meant to me, and how I hope many aspects of his like will continue to serve as an inspiration to me for many years to come.

I have been an Apple user since the earliest days, and have exclusively used Macs as my personal computers since 1984.

It was partly the stark simplicity of the early Macs, and of many later Apple products, that led me to focus my career on usability and simplicity in software engineering.

But perhaps, above all, it is Steve Job's rejection of many technology dogmas, and his advice to not be afraid of changing course, and even quitting a job that one doesn't like, that I think it is most important to take as an inspiration.

Steve Jobs quit college to pursue his dreams. While I don't recommend that people quit their studies or jobs on a whim, I certainly believe that if somebody doesn't feel they are following a life path or career path that leads to fulfilment, then changing course is critical, even if it is risky and frowned upon by others.

This encourages me to question the norms of my profession, and to try new approaches, even in the face of discouragement by others. My career passions are writing, software design and teaching. Yet a professor of computer science is boxed in by narrow criteria of how they should publish. A former Dean even told me that I should not be developing software since, that did not constitute research.

I have spent a lot of time on educational research, even though that is looked at by many others as a second-tier research topic.

Recently I have made a decision change the way I do research, even though this means fewer papers and may cost me future grants. I have a passion for what I believe is the future of software development – model-oriented programming. And I want to develop Umple as an example of this and a vehicle for exploring ideas in that domain. To do that I have to put personal effort into actually doing software engineering (including model-oriented programming itself), which takes time away from writing papers. I also have to require the same of my graduate students and have to be fastidious about software qualities such as usability, and other matters that many researchers would say should not be my concern.

So may Jobs rest in peace, and may he serve as an inspiration to help people like me who don't want to have to slavishly follow the norms of their profession and instead to follow their passions.

Why I blog: Structured procrastination?

I just came across a marvellous essay called Structured Procrastination. 

The author just won an IgNobel award for it.

It is a humorous article, but it rang incredibly true for me.

Why did I start blogging about a 11 months ago, when as a professor an researcher I am always profoundly overloaded? Because it was a way to fill in time when I was sick of working on more important tasks that were causing me stress (writing papers, reviewing, preparing grants, preparing for courses, doing administrative tasks, etc.). It was a way, just like reading the paper, or going for a walk, to exercise my brain in different directions. 

After writing a blog post, I often feel motivated to get back to the grind. Overall I have found my productivity on those important tasks has gone up substantially in the last year. Furthermore the blogging process has caused me to think more deeply about some things, which has helped aspects of my research.

I have a nice blog post in preparation showing the vast number of types of tasks professors of Computer Science have to do ... but enough for now. This little bit of structured procrastination has motivated me to tackle by two important tasks for the afternoon: Writing up some minutes and preparing for an accreditation visit.

Pure software patents vs. hybrid patents, and the ethical dilemma if one is opposed to software patents

In a recent post, I called for governments to change the rules for software patents. 

Overall I am opposed to 'pure software' patents. In many jurisdictions, as I understand it, in the wording of its claims a patent has to 'pretend' that it is a hardware patent by having a key claim that incorporates the notion of 'system' or 'processor' on which to run the software. Otherwise, so the theory goes, it is just an algorithm, which are not patentable. This is bogus. In my mind, any claim for a patent where the invention could be run on hardware that is in todays world 'generic', should just be called a 'pure software' patent. The patent offices and lawyers should dispense with the ridiculous need to cite the 'data processing equipment' that it runs on in the patent wording. Pure software patents, as I have defined them are just disguised algorithm patents.

There are, however some true legitimate hybrid hardware-software patents. These are the ones in which the software interacts with novel electronics, such as new forms of touch screen, air interfaces for mobile devices, new cameras, new sensory devices, etc. I think that patents for these should be for a shorter number of years (as discussed in my previous post) if they are mostly software, and for the standard 20 years if they are mostly hardware. However, I think that any patent with a substantial software component should have a compulsory licensing provision.

I myself am the co-inventor (along with some former graduate students, and others) on a 2008 patent application describing the ability to wind back in time the changes to a document being edited, in an animated manner. This has not yet issued as an actual patent. It turns out it is a 'pure software' patent application, as I have described above. One of the claims includes the supposedly required wording, "a processor for processing computer program instructions."

The patent application arose out of my work with IBM. If the patent is issued, I will recieve no royalties, only a line on my CV. This is because IBM funded the research and have gone to the enormous expense of filing the patent.

Given my beliefs about software patents, however, should I have refused to be listed as an inventor and have refused to help formulate the wording of the patent? That is a thorny ethical question.

Here are some arguments against my participation in the patent application:

• Perhaps I am selling my soul to the devil? Is this not the same as if 200 years ago I had participated in slavery because it was the only way to get business done? Is it not the same as if today I backed a patent on a new way to make an addictive product, or a technology that I knew would damage the environment?
• Surely one must stick up for one's principles. 

Here are the arguments in favour of my participation in the patent:

• The current legal and business environment makes patents critical to success in high technology. Without patents, one can be put out of business by a competitor who happens to have them, or by a patent troll. This can only change when the law changes.
• Getting research done in todays world requires working with companies who can fund the research. One of the major impetuses for companies to fund research is the potential for patents that might arise.
• I could have removed my name, but the patent application would have gone forward anyway.
• Someone else might have filed for the same invention. As it stood, the law in the US was, and I believe still is, 'first to file'. It is perhaps better that the patent is filed, and openly disclosed, by a prominent company like IBM that has a history of licensing patents, than by a patent troll company.
• The comparison with 'participation in slavery' or 'participation in damage to health and environment' is bogus because it is business, innovation and economic progress that stand to be hurt by the patent situation, not individual people or the environment.

I think, on balance, I made the right decision. I invite comments on this post with your perspectives.

It will be interesting to see if the patent I discussed above actually issues. I will have further comments on it if and when it does (or does not).

Later today I will have another post on patents, discussing the hot war currently going on with Google and others.

Paper about teaching with Umple was very well received at CSEE&T

I presented Umple on two occasions during CSEE&T. The first was in ASEE&T, an academy for professors who would like to learn to teach software engineering. My slides are here (or in pdf).

The second was a paper session in which I presented the following paper:

Lethbridge, T., Mussbacher, G, Forward, A. and Badreddin, O, (2011) “Teaching UML Using Umple: Applying Model-Oriented Programming in the Classroom”, CSEE&T 2011, pp. 421-428. My slides for that paper presentation are here:

Here are some of my observations about teaching with Umple, taken verbatim from the paper:

• It proved faster than writing on the board to create diagrams, with its textual mode being subjectively at least twice as fast as writing on the board, and the mouse-and-icon diagram entry mode being about 25% faster than writing on the board.
• The ability to call up diagrams from a list of example files and then edit them was something that could not be accomplished readily in PowerPoint nor on the board.
• When designing interactively, the ability to rearrange a diagram was extremely helpful, and much faster than erasing part of a diagram drawn on the board.
• The ability to show several alternative designs for the same problem proved very useful. This ability just requires pasting Umple text or loading pre-defined Umple examples.
• The ability to take an existing Java program and convert it into a model live in front of students showed them that their programming skills can directly connect to their new modeling skills. This is also something that cannot be done with other UML tools.
• The ability to generate and run good-quality code instantly helped students see that modeling is not just about pretty pictures. Doing this helped show them in concrete terms what it means to, for example, change a multiplicity or add an event to a state machine.
• Since UmpleOnline requires only a browser, it can be instantly invoked in any lecture when needed. Furthermore, students can take the same examples and instantly use them on their own laptops, which many now have in the classroom.

Here are some of the results of a survey of students using Umple, The diagram should speak for itself: Students liked Umple.

In addition, the paper showed that final exam grades on UML modeling questions improved by 9.4% in the years since I introduced teaching with Umple. The results were highly statistically significant.

Many attendees at CSEE&T told me they would like to use Umple or a tool like it, and that I seemed to have made a significant advance in helping students understand UML.