Notes the class came up with talking about “Why is software engineering more than just design, code, test”.

v  Design-Code-Test is not always the order (eg, TDD)

v  Requirements gathering

Ø  Are we building the right thing in the first place?

v  Review (as opposed to test)

v  Importance of communication

Ø  Team communication

Ø  Making communication efficient – so it doesn’t take so much time communicating what you need to do that you never do it.

§  Scheduling meetings. (Jonathan spoke about his meeting schedule with his team around the world)

§  Being willing to communicate. Having the people who need to be there included.

§  “Yeah, it’s going fine”, “all going well”, … “um I’ve been stuck on this really basic bit for the last few months”. Too proud to ask for help. Too scared to ask for help.

·         “A good team would cover each other’s weaknesses”. Chris: you’ll find it hard to progress your career if you lack communication skills.

Ø  Eg, Chris Hockings (IBM) sometimes values this over technical skill

Ø  J Giles – “don’t disappear”

§  Effects? How does the team lead manage workload and dependencies between tasks if you disappear?

Ø  Lachlan James – your communication directly effects the success of the project if you need investment buy-in, customer engagement, etc

§  Have to be passionate, rather than focused on making money (otherwise when the going gets tough the developers get jobs elsewhere!)

v  Staffing / HR

v  Code you don’t write

Ø  Zune was hit by a bug in third-party code.

§  Testing needs to go beyond just you own unit tests. Integration tests? Requirements on the testing performed by vendors?

v  Railway signalling – Tim’s talk:

Ø  Non-functional requirements.

§  Can be more important than the functional requirements (eg, safety and availability)

§  Changes the architecture of the system; harder to iterate on faulty non-functional requirements. “I’d rather have that safer; don’t use Java, we don’t like garbage collection” yikes

§  Standards, auditors, pervasively effecting all the code you develop (eg, not catching exceptions)

v  Controlling change

Ø  “If the requirements are constantly changing then how can we ever say we are finished?”

§  Good requirements at the start would help. “Requirements aren’t quite as dodgy as they seem – not just a waste of time”. “Agile methods can help if you can’t get good requirements”

·         Qld Health “didn’t get good requirements at the start”

·         “FBI requirements changing half-way through”. Different sections could not communicate. It happened with NZ Police. Staff leaving part-way through

v  GENERAL INTERESTING STUDENT REMARKS (might or might not be essay related):

v  “Rather be in a small company”

Ø  Empower

Ø  Except if I own the company! Then I want to be big!

v  “Rather not work from home” …. Why? Work-life balance? Isolation? Lots of possible reasons around working environment