SOFTWARE ENGINEERING

Dr. Abdallah Hassan

Lecture 2
 Remember
• Software engineering term was coined in late 1960s
Remember
• Brooks book (1974)
Highlighted difficulties experienced by
earlier software development teams
(too early!!)

• Mythical man-month (difficulty of

adding more people to cut time)

• The tar pit (projects can easily reach

a freezing point and fail)
Remember
• Software projects fail much more
than other type of projects

Read chapter 1 of the book

What is the current state?
• The pattern seems to continue over time

CHAOS 2020
Why software projects fail?
• Special nature of software (we need to understand)
• Traditional project management is not appropriate (we
need to take care)
• Agile methods is a proposed solution to increase the
chance of a successful software project (we need to
adopt)
Waterfall vs. Agile
• Based on a study between 2002 and 2012
• Suggestion: Agile projects are three times more
successful than waterfall projects
Warning
• We are not interested about exact figures in the previous
slides from CHAOS reports and studies
• Some researchers attack and disagree with the numbers
in the CHAOS reports

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.7918&rep=rep1&type=pdf
Why software is different
• Chapter 2 of Software project secrets
• The chapter discusses 12 characteristics of software that
make it different
1- Software is complex
• According to the author: Software is unique in that its
most significant issue is complexity

• Why do we (software people) complain? Complexity

compared to other things
• Poetry?
• Design of a machine?
• Mathematical proofs?
Why we think something is complex?

• Which of the two circuits is more complex and why???

Why we think something is complex?

• Circuit on the right is more complex because of:

1. Size
2. Individual component (element) understanding
Software complexity
• Think of a program as a sequence of instructions
• Each instruction is like a component in a circuit or a machine
• Complexity grows as number of components (instructions or
lines of code) increases

• A program of 6 lines and another program of 12 lines, which

one is more complex, and by how much???
 Measuring software complexity
• Engineering always try to quantify and measure quantities
• Software complexity is not just because of the instructions
but also caused by interactions between such instructions
• Consider the program of 12 lines
• The program is complex because
there may be an interaction between
any two instructions and we try to
figure it out, is there a relation, and
what is the relation
• Complexity = number of interactions
= n(n-1)/2 (n: lines of codes)
Measuring software complexity
• A program of 6 lines of code: complexity = 6*5/2 = 15
• A program of 12 lines of code: complexity = 12*11/2 = 66

• Conclusion: Complexity of software increases much faster

than its size

• A 100,000-line program is hundred times more complex

than a 10,000-line program

• A commercial software project can have thousands or

millions of lines anyway, so how can a developer deal with
this complexity issue???
Reducing complexity
• The key to reduce complexity is by dividing the program to
smaller components

• Complexity (number of interactions) dropped from 66 to 18

Exercise 1
A function f1() originally included 4 statements (lines) of
code,

f1() was later modified so the new version of f1() includes 8

statements (lines) of code doing the same functionality.

What can you say about complexity of new f1() compared

to the complexity of old f1()?
Exercise 2
A program is composed of four functions as follows:
f1 (5 statements),
f2 (8 statements),
f3 (5 statements),
and main (7 statements).

What is the total complexity of the program?

2- Software is abstract
• Dividing code to modules (classes, functions, etc.) reduces
the complexity but make software more abstract

• Only at individual instruction level we have accurate

description of the system behavior (what the program does)
• At higher levels, many details are hidden, with hidden things
developers can easily assume things that are not accurate
and the result is a program not doing what we expect
What makes a good programmer?
Clean code
• Clean code is code that is
• easy to understand
• and easy to change
Clean code
• Suggested easy to read resources:
1. Chapters 2 and 3 from the book by Robert C Martin
2. https://simpleprogrammer.com/clean-code-principles-bet
ter-programmer
/
3. https://cvuorinen.net/2014/04/what-is-clean-code-and-w
hy-should-you-care
/

Readings are suggested by Ahmed Khalifa

https://github.com/Ahm7dKhalifa
Clean code secret: NAMES
• Robert C Martin: “You should name a variable using the
same care with which you name a first-born child.”
Clean code: easily pronounceable names
Clean code: names show intention
Activity
• Listen to the podcast episode at:
https://anchor.fm/audcode/episodes/Software-Engineer-Mindset-
with-Mohammad-Al-Husseiny-er8q2c?fbclid=IwAR1aNFxMzBhW
AuHegzKeRiwFg06KIy0Uybf4vdDf50v_-WopEobsqsHp9wk
Write (using your own words) to describe what you understood
about the viewpoint of the speakers on the following issues:
• Using GitHub
• Remembering and recognizing names of authors
• Horizontal knowledge
• Over-engineering
• What is the most important thing you learned from the episode