Software Engineering Lesson #1: NEVER assume domain knowledge

This is a lesson for me as a teacher more than for students. Although I hope I will be able to transfer it to students too.

I have been issuing exam exercises for years now, spanning diverse topics and domains very remotely connected between each other, i.e., food, healthcare, transportation, banking, tourism, art, chemistry, and so on.

From time to time, depending on the domain of the exercise, I get questions from people asking things like:

  • is an atom bigger or smaller than a molecule?crossword-letter-tiles-hi
  • what’s the relation between a planet and a star?
  • OR EVEN: what is a cross-word? How do you play?

Usually, after a moment reflecting my disbelief, I kindly respond explaining things from relativity theory to gaming. But then, any use of this? Obviously yes! The main, first and core lesson any software engineer should always keep in mind:

#1: NEVER assume domain knowledge in your stakeholders.

If you do, you will quickly end up deluded (and you risk big in your projects, because you may start working based on statements from people that probably are not really knowledgeable of what’s really going to be needed).

Project work… serialization

Today I had a project work review session with my students. This one made me jump on my chair. A student is reporting on the problems he has on his software development project work, and finally here he comes with this small concern:
“I was serializing the data we needed and suddenly Java sent out a warning about not to serialize the classes implementing the UI. Why is that?”
I was going to suggest to serialize his project work and ship it to another university.

To learn more about serialization of object in OO see: