An Industry Perspective on What We Should Be Teaching Our Next Generation of Software Practitioners in the Universities

Title: An Industry Perspective on What We Should Be Teaching Our Next Generation of Software Practitioners in the Universities
Date: Thursday, March 25, 2021, 12:00 PM ET/9:00 AM PT
Duration: 1 hr

SPEAKER:
Paul E. McMahon, PEM Systems; ACM Member

MODERATOR:
Will Tracz, Lockheed Martin Fellow Emeritus (retired); Former chair, ACM SIGSOFT; Member, ACM Professional Development Committee

TechTalk Registration

More Resources
Software Engineering 2014: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering (ACM-IEEE CS curricular recommendations, open to all)
The Essence of Software Engineering: Applying the SEMAT Kernel (O’Reilly book, free for ACM Members)
Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement (O’Reilly book, free for ACM Members)
Scrum Master: Scrum for the Team (Skillsoft course, free for ACM Members)
Transition to Scrum: Agile Foundation to Scrum (Skillsoft course, free for ACM Members)
Software Engineering: Architecture-driven Software Development (ScienceDirect book, free for ACM Members)
Agile Software Architecture: Aligning Agile Processes and Software Architectures (ScienceDirect book, free for ACM Members)

We find no graduates seem to know about accessibility for people with disability even though it’s required by law in many countries (eg Section 508, EN 301 549, and the DDA in Australia). What is the broader industry perspective on this missing link in what students are being taught?

The tech field is getting bigger and more people with non STEM background are now finding their way into the field, do you think this is also contributing to the growth of the field?
And how do you advice someone who wants to dive into Data Science or any tech field without having a STEM background?

1 Like

More than 99% of code in the world runs in embedded devices. I work in the specialised area of safety-critical embedded systems: railway signalling, medical devices, (semi-)autonomous cars, surgical robots, warehouse robots, etc.

A few years ago I gave a keynote talk at an IEEE conference (sorry, but I wasn’t invited to an ACM one) and found I had a room full largely of academics. I asked for a show of hands of how many worked in a department that taught the skills required for embedded programming. Very few hands went up — many of the people present thought that Java was a programming language! I then refined the request to those who taught the techniques of producing safety-critical embedded code. One hand remained up.

The safety-critical area is growing very fast and we are desperate for new blood, yet we cannot get such people from the universities.

This is really important
There’s many “industry oriented universities” with short academic programs that are skipping essential engineering and mathematics courses in favor of only programming-oriented courses

Does Computing Ethics have a place in the Computer Science (and related) curricula? And if so, how big should that place be, i.e one off ethics course, integrated ethical/social considerations per each computing course, interdisciplinary collaborations (e.g. between Computer Science, Social Science, Law etc) for teaching ethics, etc ?

At Grand Canyon University, we look for ways to introduce experience in reading other people’s code and refactoring it without breaking previously working functionality. We know students usually build something from scratch and with their own bias on knowledge and skill. By expanding their code exposure, they are more successful when they enter the industry.

Question 1: What is your position on Watts Humphrey’s Personal Software Process and Team Software Process as ways to developing a personal method?

Answer: I believe both PSP and TSP are very good processes, but keep in mind these are both processes, and Essence is not a process. The five checklist items I referred to at the end of my presentation that are part of Essence are intended to help developers become better estimators and better at answering the question, “When will you be done”, which is a large part of what Watts was getting at in PSP with regard to learning to measure yourself in a disciplined way. You can use the Essence checklists, if you use PSP or TSP, or any other process including Scrum, or a Waterfall variant.

Question 2: What do you think universities should stop teaching to make time for teaching the material you suggested?

Answer: I answered this question at the end of my talk, but I will restate my answer here. I don’t think we need to stop teaching anything to teach what I propose. I am proposing the insertion of concrete examples/stories from real industry situations (I gave a number of these examples/stories in my talk) into each course in the University. Then just change the way certain things are taught to make them a little more efficient, thus making time for the added stories/examples.

Question 3 : Agile methods have been a buzz for at least a decade. It seems that the buzz is fading and becoming “real”. Critical views on agile i.e. Antipatterns and “survival guides” are popping up. Any comments on that shift?

Answer: All methods (agile or traditional) have weaknesses. It is to be expected with the popularity of agile methods that we would be seeing antipatterns and survival guides to try to address the common weaknesses people run into. This is one motivator for Essence, which as I said in my presentation is NOT a method itself. It is a common ground of essentials that underlies all successful methods and, as such it can help us identify the weaknesses in any method including agile methods. Many of the examples/stories are referred to in my talk are, in fact, anti-patterns that we often see in organizations regardless of the method they choose to use.

Question 4: Natural language may not be precise enough to express procedures; process logic.

Answer: What I am suggesting is not intended to replace teaching computer programming languages that do need to have precise syntax/logic. What I am suggesting is adding stories that communicate the real kinds of situations that software developers are certain to face in industry, so they don’t get a big surprise when they leave the university. These stories are best communicated with natural language.

Question 5: I don’t know about this. In many universities I have been in, the capstone project (senior design projects) has real stakeholders and mostly ambiguous requirements.

Answer: I know there are some universities where this is true, but, as I mentioned in my presentation, I have also heard university professors say their students don’t have real stakeholders and they don’t have ambiguous requirements. It would be good to hear more of the stories and lessons from the universities that are already doing this and if they have received feedback that the students are better prepared because of these capstone projects. What I am suggesting is to supplement courses with these real stories which can support capstone projects if you have one, and at least give students who don’t have the benefit of participating in a capstone project some ideas of what they should expect when they leave the university.

Question 6: What is the percentage of active practitioners teaching in universities in comparison to academics?

Answer: This is a good question and I personally don’t know the answer. If anyone who reads this does have a reference to a good answer please provide feedback. I do believe we should be encouraging more active practitioners to share their knowledge with students. I address this further in a later question.

Question 7 : Do you have any tips for balancing the limited time available in an academic term with the simulation of difficult stakeholders and late hardware?

Answer : This is exactly why I like telling students stories. I think they can understand the kinds of stories I shared in my presentation and it doesn’t take a lot of time to tell the story and then have a follow-on discussion related to the associated Essence Alpha and checklist(s). Admittedly, this might not stick with the student to the same degree as actually having a real project with a real difficult stakeholder or some real ambiguous requirements they have to work through, but it is one way to deal with the time constraint of an academic term.

Question 8: How are NFRs such as performance and reliability captured in this framework? Students are seldom taught to be aware of these.

Answer: I answered this question at the end of my talk, but I will reaffirm my answer. Often students find non-functional requirements difficult to grasp. This is a perfect example why we should use real stories from industry to explain what happens when non-functional requirements are not appropriately addressed. There are many such well-known stories that could be shared especially in the area of performance, such as the Obamacare Website problems. Telling stories is the best way I know to make the point stick short of actually having the time to conduct a real project. Using the related Essence checklist can then serve as reinforcement and as a reminder once they leave the university and go into industry.

Question 9: As an active undergraduate student, would Essence and root cause analysis be taught in conjuncture with something like operations and management course? Or would these concepts be taught in their own course?

Answer: It could be done either way, but what I am proposing is to spread this training across many courses with relevant examples to each course inserted. Root cause analysis isn’t something that should be limited to just one course. Students should learn this way to think and use it throughout their career wherever and whenever appropriate.

Question 10: Grand Canyon University hosts a tech advisory board session each semester - the topic of changing or unclear requirements has come up. It is hard to teach to that scenario because education requires having clear expectations. Do you think providing User Stories and Task lists meet the need for students?

Answer: I don’t believe User Stories and Task Lists are sufficient. They provide one way, but the student should be taught that this is just one way and the company they end up working for may or may not use this approach. I believe you can set clear expectations in the university by adding real world scenarios to class content with changing or unclear requirements, having classroom discussions on those scenarios, and then testing the students by asking them to describe the root cause of the problem discussed and possible solutions.

Question 11: Is there a place we can find all of the checklists?

Answer: Yes. On the last slide of my presentation you will find how to access all the checklists from the SEMAT website.

Question 12: Do you think universities should teach students things that change every few years in the real world? (I’ll give you a hint. The answer is NO!)

Answer: I didn’t need the hint. --::blush:) You are right. The answer is NO. This is a major driver on why we developed Essence. That is to teach students what they can take with them and use for a lifetime in industry. This is much more valuable content for the student.

Question 13 : Why should universities teach things that change every few years?

Answer : See the answer to the previous question.

Question 14: When should we be introducing Essence into a curriculum? How do I teach this to my freshman students, many of whom have zero programming experience and may need very structured assignments?

Answer: As I said at the end of my presentation and as I said in my answer to question 2, I think Essence should be distributed throughout a Computer Science curriculum and taught in a “stealth” mode by actually using it through concrete examples where appropriate. Thus, the freshman student might get a little introduction to it, and then learn more about it in other courses where other examples might be more appropriate. If you have a course on software engineering methods that would be a good place to talk about Essence from a big picture perspective. Also, if you have a course on software engineering management that would also be a good course to talk about the general idea of Essence from a perspective of assessing progress and locating trouble spots in your project. If you have an ethics course this would be a good place to talk about the importance of getting all the team members and stakeholders in agreement with the ethical principles they will follow on the project… and so on…

Question 15: Is linking the architecture to the requirements part of the check list?

Answer: Essence doesn’t provide “ hard links” between architecture (or software system- the alpha that includes architecture checklists) and requirements (requirements alpha) although there is certainly a relationship. The essentials of architecture are addressed in the Software System Alpha, and we say that the Software System Alpha “fulfills” the intent of the Requirements Alpha. We say it this way for the reason I explained in my talk related to the “Enough Addressed to be Acceptable”. Sometimes you don’t need them all addressed to “fulfill” the intent, as I explained in the “Requirements are not always requirements” example.

Question 16: Is linking requirements to business and engineering needs part of the checklist?

Answer: As I mentioned in the previous answer, Essence doesn’t provide “hard links” between requirements and other areas, such as business and engineering needs. The essentials underlying “needs” are addressed in the Opportunity Alpha and there certainly is a relationship between the “needs” and the Requirements. We say the Opportunity helps to “focus” the Requirements. The specifics of this relationship depend on the practice your organization decides to use for requirements gathering (e.g. user stories, use cases etc.). The reason I am being careful with the word “link” is because Essence is independent of method or practice choice. What we say in Essence needs to be true for any method or practice. This is also why it is so useful to teach students.

Question 17: Do you think this type of education will help minimize “imposter syndrome?”

Answer: I haven’t heard the phrase “imposter syndrome” before, but if it means one practice pretending to be new when it really is fundamentally the same as another known practice or method, the answer is Yes. This was one of the goals underlying the development of Essence. That is, to provide a common ground from which to compare practices and identify real discriminators. Therefore you can use Essence to determine if there are no real discriminators and a certain practice is thus effectively nothing new.

Question 18 : Examples of things that change every few years are software development methodologies (SCRUM/Agile/Essence/XP).

Answer: I disagree with your putting Essence in this list. Essence is not a methodology. The intent of Essence is not to be used as a method to develop software. It is intended to be used together with whatever method your company has chosen and therefore it doesn’t change every few years even if the method your company is using changes or if technology or tools change. Again, this is a powerful motivator for learning and using Essence. It isn’t going to keep changing every few years. There may be minor improvements over the years, but it will essentially remain pretty stable.

Question 19 : One issue I see in industrial software is office politics. For example, resistance to change. When bringing improvement to an existing process or a system, existing people who created the original system would perceive this as an implicit critique to them and would fiercely oppose any these changes or enhancements. How would this be taught to students? Thanks.

Answer: Good question. I answered this question at the end of my presentation. But to emphasize the point I made – this is a primary reason why I use Essence in what I call “stealth mode” as I discussed in my presentation. I don’t think we should start from the supposition that something needs to change in an organization because that is a setup for opposition, as you say. The starting point should be observing whatever your organization is currently doing and understanding what is perceived by those in the organization as not working well. Then we use Essence (in a stealth mode—just stimulating normal conversation) to help identify the root cause of the problem. From there we can all discuss the possible solutions and reach agreement. This approach I have found can help to diffuse any emotion around change by taking the time to look at and reach agreement on what needs to be done to help the organization be successful.

Question 20: Where do we get all the relevant stories? I have some industry experience from before joining my university, but my experience is not extensive enough to know many critical stories of how company’s decisions impacted the work with the clients.

Answer: This is a great question. I have personally shared many stories from my own career (such as in this presentation) and stories that have been shared with me by my clients (also in books I have published—for example my “It’s All Upside Down…” book has many real stories as does my “Integrating CMMI and Agile…” book). I often encourage those with industry experience to share their stories through publications and by giving talks. One way is to invite industry personnel to come into your classroom and give talks on real experiences with a focus on the trouble spots or challenges faced. You could then have your class discuss the stories shared afterwards and see if they can identify root causes of problems discussed and possible solutions using Essence Alphas and checklists to guide the discussion.

Question 21: Imposter syndrome is a feeling by entry-level programmers that they do not have the knowledge, skills, or experience to be successful.

Answer: Ok. I think I misinterpreted what this phrase means in a previous answer, but my answer is still Yes. Telling stories can help minimize this syndrome among beginners because it will help them feel like they have been in these situations just by hearing the stories.

Question 22: I must admit, I do not fully understand the concept of requirements not being requirements yet. Any clarification would be helpful. Thank you.

Answer: I tried to explain this in the talk, but let me try again and see if I can simplify it. Often something is written as a requirement because the customer (or person writing the requirement) only knows one way to get their needs met. But what they are asking for isn’t really a requirement, but rather one way to achieve their real need which is something else more fundamental. When they learn more about the capabilities of the system that has been developed they may find another way to meet their need and thus what they thought was a requirement doesn’t turn out to really be needed by the customer. Hope this helps. You can often find lots of examples of this when a system is given a new user interface with different ways to achieve a user goal.

Question 23 : Can you come back on the Scrum practices that are implemented, poorly and not at all? What are they in each category? Thanks

Answer: Thanks for asking this question. It isn’t one set (or one category) that are always implemented poorly or not at all. It varies with each company. For example, some organizations who claim to be doing Scrum don’t actually do retrospectives at all, while, of course, many companies conduct very effective retrospectives. Some organizations implement their daily standup poorly and so on…

Question 24: So that means, checklists are not enough but we should also group them based on weight or priority? So that if the more weighted ones are not checked, you shall not pass.

Answer: This question is in relation to my story about the Senior experienced personnel and critical thinking. The answer is Yes, but be careful how you implement this. Which checklists have more weight or more priority depends on the situation so please don’t think you can do this assessment of priority and weight just once for a given organization and say that is the way we use them in our company. This is why you need to teach your developers how to think and make better decisions on a daily basis. I have seen organizations who try to dictate these answers from the top and it does not work. It actually will cause the use of Essence to fail. It leads to just using the checklists in a “check-the-box” mentality which is not what we are looking for. We want your people to learn to use the Essence checklists to help them make better decisions given their own context. Essence can’t make the decision for them. Essence doesn’t know your context and this is crucial for each decision.

Question 25: If we conclude, we can say that students can learn from these stories and instead of following the usual tradition of “learning by making mistakes”, they can learn from others’ mistakes.

Answer: Yes. That is what I am saying. I am not trying to say they won’t still make mistakes and learn. We all must be continual learners, but we can share what others have learned so our new developers don’t have to relearn what experience has already taught us. That is a big advantage of using Essence.

Question 26: Thank you very much Mr McMahon, so so interesting, holistic thought useful in many knowledge areas to teach in the university.

Answer: Thank you for the nice comment. Good to hear you find it useful.

Question 27 : We have a whole mashup of degrees that could lead to programming careers: CS in Arts/Sciences College, CS in Engineering College, Computer Engineering, Software

Answer: Yes. And as I suggested, I believe using Essence together we concrete real stories could be integrated into all of these degrees to help the student have a better idea what they will face when they leave the university and go into industry.

Question 28: where are the cards downloaded from?

Answer: You can find the url on the last slide of my presentation.

Question 29: More than 99% of code in the world runs in embedded devices. I work in the specialized area of safety-critical embedded systems: railway signaling, medical devices, (semi-)autonomous cars, surgical robots, warehouse robots, etc.

A few years ago I gave a keynote talk at an IEEE conference (sorry, but I wasn’t invited to an ACM one) and found I had a room full largely of academics. I asked for a show of hands of how many worked in a department that taught the skills required for embedded programming. Very few hands went up — many of the people present thought that Java was a programming language! I then refined the request to those who taught the techniques of producing safety-critical embedded code. One hand remained up. The safety-critical area is growing very fast and we are desperate for new blood, yet we cannot get such people from the universities.

Answer: The situation described is one of the motivators for Essence. As I mentioned in my talk you won’t find specific principles and practices in Essence and this includes safety critical principles and practices. This is because not all software development requires these specialized skills. It is expected that organizations develop additional alphas and checklists extending the Essence kernel addressing the specific needs of their domain.

Question 30: This is really important. There’s many “industry oriented universities” with short academic programs that are skipping essential engineering and mathematics courses in favor of only programming-oriented courses

Answer: Yes. This is a good point and again it is a motivator for Essence. Teach the core fundamentals that are relevant to all successful software development. We are not saying, as mentioned in the previous answer related to safety-critical needs, that this is all that computer science students need to know. But it does ensure they understand the essentials that should always exist for successful software development.

Question 31 : Does Computing Ethics have a place in the Computer Science (and related) curricula? And if so, how big should that place be, i.e one off ethics course, integrated ethical/social considerations per each computing course, interdisciplinary collaborations (e.g. between Computer Science, Social Science, Law etc) for teaching ethics, etc ?

Answer : Absolutely yes. I also mentioned this in my talk. Essence does not prescribe ethical principles, but it does remind teams that stakeholders and team members need to agree on the principles and practices they will follow and that includes ethical principles. It is my view that one of the best ways to handle this is to integrate this discussion into appropriate courses with concrete stories/examples. For example, a course on databases could have a discussion on privacy and the responsibilities of a database developer in regard to protection of personal information. Similarly, a course in artificial intelligence could have examples/stories that discuss the potential consequences and responsibilities of the software developer related to controlling self-driving cars and so on…

Question 32 : At Grand Canyon University, we look for ways to introduce experience in reading other people’s code and refactoring it without breaking previously working functionality. We know students usually build something from scratch and with their own bias on knowledge and skill. By expanding their code exposure, they are more successful when they enter the industry.

Answer: This is a great way to help prepare students for what they will face in the University because more and more software developers are working on legacy code rather than developing new code. I would also suggest this is another great application for Essence, as students can use Essence in assessing legacy software looking for root causes of potential problems and potential fixes to these problems. The results of such an assessment could be class discussion item.