The Principles of Sustained
Software Development
Lecture 2
CIS 6101 – Software Processes and
Metrics
1. Introduction
• We normally develop software based on required features, bug
fixing, and a plan.
• Plans are typically linear, start with analysis and design,
continue with coding, testing, fixing, tracking against the plan
and customer use.
• This engineering plan that does not work too well for software.
• Real world of software development involves a changing
ecosystem of technology, competitors, and customers
• Until programmers are exposed to this commercial system,
none of this seems significant.
– Then, all of a sudden, they write code and must live with it.
– And, the code they live with is not just their code either!!
Bridge from Academic to Practical
• Must establish a mindset to create a culture of
software development for sustained
development despite surrounding complexity
• Without the proper mindset, developers fall
back to traditional linear approaches due to a
degree of comfort and familiarity.
– Here, too little structure in code-then-fix
development) or too much bureaucracy which tends
to stifle innovation, flexibility, and change tolerance
– the very properties a dynamic and changing
environment requires.
Practice versus Principles
• Practices often viewed as templates for success.
• In truth, practices must be tuned to the situation and the
team. (no one size fits all!)
• Bureaucratic rules are in place for predictability, which is
often achieved but at the cost of innovation and ability to
respond to customer requests.
• We can implement practices, but we need the right mindset
/ culture to support the practices, for you’d be better off
doing ad-hoc software development.
• Before a team talks about development practices, we need
to first focus on the principles to be followed.
• Principles guide us every day making tradeoffs and fostering
the right mindset and culture for the team and organization;
• Practices follow from the principles you choose to adopt.
2. Why Principles are More
Important than Practices
• Similar to difference between vision and features.
• Unsuccessful projects start with defining features
designed to meet user needs. (the Whats)
• Successful projects start with a clear user need and
vision of HOW to meet that need.
• The vision is simple and can be used to develop an
initial set of features and a prototype for customer
feedback, needed to refine the feature set.
• This is iterative development (as it is called in agile
software development)
Key Aspects in Vision-Oriented
Approach to Produce Development
1. A user need and vision so it is clear WHAT is
being built
2. Rapid refinement to adapt to change
3. A close relationship with users so they can
provide timely feedback
4. Continual learning to refine the product so it
best meets user needs while avoiding
unnecessary features.
Rules (Lists of Practices)
• No magic set.
• Our education specifies a set of rules (stepby-step procedures) to solve problems.
• But problems arise as we rarely anticipate
the role of complexity in the application of
the rules.
• Rules work fine for simple problems but
break down as complexity increases.
Principles and Practices
(Vision and Features)
• Principles are like vision; practices like features.
• Principles define what you want to accomplish; practices
define how you want to go about it.
• Too much today is around sets of practices (best practices)
– Again, following a set of practices implies safety, comfort,
completeness, predictability, sense of confidence…
• Practices are important, but if you don’t know what you
are trying to achieve, then efforts will be misdirected.
• More important to recognize WHAT team is trying to
achieve rather than HOW they achieve it.
Principles and Practices
(Vision and Features)
• Good teams listen to practices and ask
questions as to what (vision) they are trying to
achieve, and apply the practices as needed.
• Great teams see through the rule-based façade
(practices) and see the rules as a solid
foundation to build on.
• Great teams work from a clear user need (high
user value through features and high quality)
and a vision (the principles) and continually
learn and refine their approach (the practices) as
their project progresses.
Three Elements to Sustainable
Development
• Summarizing: a development team needs:
• 1. A vision and set of guiding principles that define what
needs to be accomplished
• 2. Practices that are consistent with the principles (these
are not a set of rules; rather building blocks that your team
should refine and add to over time through continual
improvement of your approach to software development)
• 3. A tight feedback loop of experimentation, learning, and
refinement so that during the development of the product
the project team is able to change, modify, and enhance
their practices as required so the team can best fulfill the
principles (vision).
3. Applying the Principles of
Sustainable Development
• Given a clear vision and desire to achieve sustainable
software development, these principles apply:
1. Continual refinement of the product and project
practices
2. A working product at all times
3. A continual investment in and emphasis on design
4. Valuing defect prevention over defect detection
Practices support these principles.
Let’s look at each principle in turn.
Principle: Continual Refinement of
Product and Project Practices
• This is a recurring theme in software development.
• Software is complex and must evolve over a long period
in the face of changing requirements and evolving
ecosystem
– Markets, partners, technologies, and competition
• Things change during development
– Team must plan for change by employing practices to
support managing change.
• Thus team needs user involvement and lightweight
practices to keep on track, monitor progress and risks.
• The set of practices establishes the heartbeat (rhythm)
of the project and is a must for successful sustained
development.
Principle: A Working Product at All Times
• Keep product in a near-shippable state at all times, even if it is not
functionally complete. Product needs to be in a working state.
• Means emphasis of team is a working product and not producing
documentation of user requirements, software design, etc. that ‘might’
lead a product.
• This is a key principle of agile development.
• Best way to get feedback is to provide users something they can really
comment on, even if it is a work in progress.
– Documentation, even really good documentation, does not elicit the same quality of
feedback that a working product can.
– Even prototypes are better than a document.
• Working documents also show the time is being spent on productive
activities. If too much time is spent on documentation, then time will
need to be spent on getting the product back to a working state, which is
time often wasted.
Principle: A Continual Emphasis on Design
•
Design (both good and poor) is very obvious and heavily
influences purchasing decisions.
– Design decisions are made every day and by all members of the team.
– Team need so allow itself to make design changes.
• Do not try to anticipate every future use at beginning of project.
• Design only what you need today while not closing out
possibility of future enhancements.
• Agile development requires considerable design – maybe even
more than traditional design.
• Good design practices extend the life of the product by keeping
implementation in a healthy state
– fosters maintainability and changeability – essential nowadays;
– Ensures a simple long-term design vision.
Principle:
Value Defect Prevention over Defect Detection
• Defect detection involves trying to discover and fix problems
after changes have been incorporated into software.
• Prevention emphasizes catching defects before changes are
merged into the software.
• Assumption in defect detection is on defect tracking systems,
manual testing efforts, and errors reaching the customer.
– Organizations invest a lot in QA activities and in testing.
– Tracking errors and their resolution, prioritizing, reporting, assigning
fixes to proper OPRs, etc. is a huge task – and expensive.
• Often, there is a virtual wall between developers and testors.
• Developers develop new software and provide to QA / QC …
to test prior to release. (more)
Principle:
Value Defect Prevention over Defect Detection
• In defect prevention, defect tracking systems are still needed but
importance greatly reduced.
– Have lower defect counts. Teams have multiple safeguards in place.
– More regression testing, ensuring bug fixes properly testing, and more.
• Heavy emphasis on automated testing to focus on testing the product in
ways that the customer will use the products.
• No virtual walls in defect prevention culture; ideally testers are part of the
team and quality is spread evenly between developers, QA, and testers.
• Defect prevention is required for sustainable development
– Ensures team is highly efficient and is creating value for customer not on
wasted effort.
– By minimizing defect numbers, development teams are able to have productive
conversations with users about features and workflow because users are able
to use the product in realistic ways.
4. Culture, by Descriptive Words and Phrases:
Disciplined
• Team must be highly disciplined in approach and be goal focused.
• Work must be done properly w/no shortcuts.
• Work is really done when they say it is.
• Agile development has been often labeled as being undisciplined.
• Consider: Differences between Discipline and Ceremony
• Ceremony – required actions must be performed
– Requirements document before a certain milestone; Milestones such as a
feature freeze, Weekly status meetings; Design documents; more…
• Discipline - Agile teams minimize ceremony by keeping to task;
producing results (a working product ).
– Unfortunately, people mistakenly believe unless documents are created,
there’ s no discipline, but creating documents is no guarantee a prescribed
process is being followed.
Culture, by Descriptive Words and Phrases:
Responsible
• Team must be responsible for its work and not play the part of a
victim. No blame game!
• Victims go along with a decision and then say, “I told you so.”
• Responsible teams have the courage to take on any situation and
do not get swept up by events.
• They trust others to do the best they can and are diligent that
nothing falls between the cracks.
• Never say that ‘that can’t be done.’
Culture, by Descriptive Words and Phrases:
Leadership
• Team has multiple leaders who work together
• Leaders are not just the managers, team leads, or coaches
• Leaders know their greatest success is when they can help others
to succeed and give them the opportunity to receive the accolades
they deserve, who view success as a team accomplishment and
failure as a personal responsibility, not an opportunity to
apportion blame on others.
• Unfortunately, these people are few and far between and are
rarely promoted into senior management because they lack the
charisma, high-volume talking, and massive ego and selfconfidence – the traits often associated with getting ahead in the
corporate world.
Culture, by Descriptive Words and Phrases:
Visionary and Tactical
•
Effective teams strive for an optimal balance between visionay
(thinking about the long term) and tactical (focusing on today’s
problems) and this balance changes over the course of the project.
• Early in project, there is heavier emphasis on being a visionary;
later, emphasis should be place more on tactics related to finishing
the project.
• Projects fail when there is too much emphasis on tactical issues
too early in the project.
• Great teams are able to balance the two at each moment in the
project.
Culture, by Descriptive Words and Phrases:
Shared Sense of Urgency
• Important that every one on team shares the same sense of
urgency to complete the project.
• If business people are more concerned about completion and
developers are more concerned about the perfect architecture,
failure will result.
• A shared sense of urgency is also the most important factor in
building eams.
• It is NOT compatible personalities or team building exercises or
even mutual respect that makes the bet teams; it is a shared goal
or aggressive but achievable deadline that the team uses as a
rallying cry for getting the project done.
Culture, by Descriptive Words and Phrases:
Shared Sense of Highly Collaborative
• Collaboration is a vital success factor in sustainable development.
• Good teams are able to work together, embrace the differences
between personalities and rules and stive for a successful project.
• They recognize that there are clear rules for each of them to play.
• Always there and should be done sub-consciously.
• Must be done in person and not via email or voice mail, as much
as possible because that is the most effective form of
collaboration.
Culture, by Descriptive Words and Phrases:
Complementary Talents and Skills
• Great cultures recognize talents and skills from each other.
• Too many companies are focused on skill alone and recruit only for
skills.
• But skills can be taught, whereas talent cannot.
• Software development companies are perfect examples where
people who are talented at complex problem solving make
excellent programmers.
• Yet, most ads still look for a certain number of years of experience
programming in a particular language when what they should be
looking for are people who are talented problem solvers.
Culture, by Descriptive Words and Phrases:
Continually Improving and Learning
• Continual improvement and learning is a vital element of
sustainable development.
• Great people and teams continually learn and refine their projects
and how they approach projects.
Culture, by Descriptive Words and Phrases:
Change Tolerant
• Great teams understand that change is necessary and desirable.
• They also understand change must sometimes be made in the face
of conflicting or incomplete information.
• Just because a decision is made at one time does not mean it
cannot be changed or modified as new information becomes
available.
• So teams must be change tolerant.
Culture, by Descriptive Words and Phrases:
Risk Aware
• Risk is a common element in all projects.
• Effective teams are always aware of risk and are able to
differentiate between real and perceived risk and are not afraid to
make decisions with the best information available in the face of
possible risk.
• Always looking for ways to reduce risk too.
Culture, by Descriptive Words and Phrases:
Fun
• Can’t always choose what you do, but you can choose how you do
it.
• Good people and teams recognize this and find ways to make work
more fun for their co-workers and customers.