coding for "real life" safe coding considering software industry expectations in...

CODING FOR "REAL LIFE"Safe coding considering software industry expectations in programming

• Boráros-Bakucz András• Óbuda University, Budapest, Hungary,

Kálmán Kandó Faculty of Electrical Engineering• Ericsson Hungary Research and Development

Software development, Release Program management

> whoami

• Basic programing courses usually focus on basic level knowledge without deep understanding of C and C++ compilers

• But some good practices can be learnt early and used forever… resulting less execution or maintenance cost in business processes as well

• Problem of large scale, industrial software development• Quality vs. team development

Introduction

• Central User Database failed in Great Britain• 2 month before Olympics in London• Approx. 18 million people could not use his mobile for more than 20

hours• Headline in newspapers

What Bad Coding may Cause

• Nobody wants…

Fame

• Reasons• Quite new product• Distributed database system: multiplicated data could never be totally the

same (it must be consistent)• Tested under overload situations only in lab environment• Quality issues, for example no stable enough build system

• What happened• Support/maintenance activity was done during peak hours• System went inconsistent• No one really knew how to get it up again• Support persons downed radio access network links to build location

database from scratch

What Bad Coding may Cause

CODING PRACTICES

› Limit internal operations, which depends on data content (internal data consistency) • No need to behave “good” in case of data inconsistencies (software

faults in our case), but need to handle them smoothly• No software crash allowed• Good example: string copy functions

› Use timeout for limiting operations waiting for any kind of external answer (see later)

Limit all operations

• You should never use strcpy in real life. Why? • It is an unsafe function rewritten as strncpy which limits the

maximum bytes copied

Copying Strings

Copying Strings

Copy Strings

“If ifs and ands were pots and pans

there'd be no work for tinkers' hands.”

›Exclude everything possible.›Do not skip else.›Most frequently true first.

ConditionalPractices

Exclude everything possible

• Use “smaller then” instead of equality check

• Check for value groups instead of individual values if possible

Exclude everything possible

• System managers, software architectures often not handling negative situations• Requirement does not say anything what software should do if a

condition does not happen

• Developers always need to think what should happen if condition does not meet• Write an else branch all the time and remove only if you are sure

that it concludes on right behavior• Positive path is only the smaller part of development (~30%)

Do Not Skip Else

• Requirement: if your program receive an “echo-request” message, send back an “echo-reply”

Do Not Skip Else

Do Not Skip Else

• Requirement:• Count ‘a’ and ‘e’ letters separately in a string.

Most frequently true first

• Requirement:• Count ‘a’ and ‘e’ letters together in a string.


CONCEPTS

• What cases you must check validity in functions’ input parameters?

• Trust your own software• Either it is your code or some of your colleagues’ code• You should trust internal interface descriptions• No need to check each and every input parameters’ validity

• Do not trust any data received on external interfaces• External interfaces can be “noisy” or “evil”• Or disconnected any time (unknown message received)• In multivendor situation different companies may differently understood

standards

Shall I trust input parameters?

http://xkcd.com/327/

Tales of the Little Bobby Tables

• Sanitize your (database) input• Check each and every human input and… • Be protective, just permit what you are prepared for• For example: hard space, soft space (hyphenation)

Tales of the Little Bobby Tables

• Use timers to limit operations should be finished by an external module in a certain time

• Timers counting (mili)seconds and when time expired a function is executed

• Do not trust your external input, always protect your code

Do not Wait Forever

• General principle of lean and agile (iterative) methodologies

• Let your software faults shown as early as possible• Do not hide problems (for example

unhandled else branches)

• Continuous integration• Automatized unit testing• Nightly (or more frequent) builds• Regression test run• Visibility of code quality

Fail Fast

› Always remember the KISS principle.

Keep it simple and stupid.

› WP: “A design principle noted by the U.S. Navy in 1960. Most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.”

› Variations: "keep it short and simple" and "keep it simple and straightforward"

KISS

• After two weeks very hard to remember what you did and why some variables in your very detailed algorithm

• There are more and less self documenting languages (Pascal vs. C)

• There are some editorial steps you can use for make your code easy to understand later by you or anyone else

• Proposals:1. Descriptive variable names (long)

2. Descriptive function names

3. Format source code in a coherent way

4. Write comments

Self Documenting Code

› A set of programming rules must be followed in coding by all developers

› Give a common base for all new development

› For example:• Logging and tracing rules• Software start // order of the components• Priority of new feature’s threads• How your code should handle failover or takeover• GUI rules

Coding Rules,Design Rules

• Make your code more readable, easier to understand• All your products’ components’ source code should look the

same• Contains

• Comment conventions• Indent style conventions• Naming conventions• Best programming practices• Programming rules of thumb (Rule of three, Pareto, Ninety-Ninety)• Programming style conventions

• Example: Google C++ Style Guide

Editorial Rules,Coding Conventions

• Productified source code goes to maintenance after deployment

• Effective coding increasing complexity, reducing readability probably reducing maintainability

• Maintainability versus effectiveness – needs to find the right balance

Maintainability

METHODOLOGIES

Waterfall and Iterative Methods• Give me the possibility to handle it as a big chapter…

SUMMARY

› “Do not assume anything.”› Check everything, until you are sure how the system,

features or function works• General positive (non-erroneous) return value is 0• but printf() returns the number of written bytes to stdout

› Q: Why scanf( “Give me a number: %d”, &i );

you are not able to type a number there?

Summary: Rule #1

› “Do not assume anything.”› Check everything, until you are sure how the system, features or

function works• General positive (non-erroneous) return value is 0• but printf() returns the number of written bytes to stdout

› Q: Why scanf( “Give me a number: %d”, &i );

you are not able to type a number there?

(A: Pattern matching.)

› These functions are fossils, but you should not underestimate the power of “historical reasons”

Summary: Rule #1

SOFTWARE DEVELOPMENT METHODOLOGIES

Methodologies

• Waterfall• Prototype model• Incremental• Iterative• V-Model• Spiral• Scrum• Cleanroom• RAD

• DSDM• RUP• XP• Agile• Lean• Dual Vee Model• TDD• FDD

Waterfall

• Sequential design process

• Progress is seen as flowing steadily downwards (like a waterfall) through SDLC

Waterfall• Do we know all requirements in the beginning?• If we have a problem we need to go back several phases.• Results long project time, usually year or more.

• Slow release cycle.

• Finding problems early is cheaper than later.• Proven to Waterfall only.

Waterfall #1• Jump to next phase only if the prior one is completed

• PROs• Detailed early analysis cause huge advantages at later phases• If a bug found earlier, it is much cheaper (and more effective) to fix

than bugs found in a later phase• Requirement should be set before design starts• Points to importance of documentation (minimized “broken leg”

issue)• Disciplined and well-structured approach• Effective for stable software projects• Easy to plan from project management point of view

Waterfall #2• CONs

• Changes are expensive• Client does not explicitly know what he or she wants• Client does not explicitly know what is possible to have • Need to finish every phase fully• Long projects, difficult to keep the plan• Designers may not know in advance how complex a feature’s

implementation• “Measure twice, cut once”

Incremental Build Model

• A model between waterfall and iterative methods

• The model is designed, implemented and tested incrementally (a little more is added each time).

• Finished when satisfies all the requirements.

• Combines the elements of the waterfall model with the iterative philosophy of prototyping.

• How long test phase needed – it limits the minimum length of a development “increment”

• Non functional requirements may cause problems

• Also hard to place the efforts needed for development environment creation

Iterative Methods

• Iterative methods are different combinations of both iterative design or iterative method and incremental build model for development.

Incremental vs. Iterative

Iterative / Prototyping

Effort in Iterative Development

Case Study• For small impacts

Start ofStudy

End ofStudy

Study Backlog

Product Backlog

EPP Node

Start ofExecution

< 2 weeksOB WSMD

created

MDErequest

MDE QSsent back to CU

MDE POreceived

Execution &Verification

Release & Delivery

PD0 PD3

Prototyping

• Creating prototypes of software applications i.e. incomplete versions of the software program being developed

• A prototype typically simulates only a few aspects of, and may be completely different from, the final product.

Spiral Model

• Combining elements of design and prototyping-in-stages

• Combines the features of the prototyping and the waterfall model

• The spiral model is intended for large, expensive and complicated projects

• Advantages of top-down and bottom-up concepts

Background

• Top-down• deductive reasoning• analysis or

decomposition• Descartes• G => 1

• Bottom-up• inductive reasoning• synthesis• Bacon• 1 => G

RAD

• Minimal planning and fast prototyping.

• Developing instead of planning

• The lack of pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

Cleanroom• The Cleanroom process embeds software development and testing within a statistical quality control framework.

• Mathematically-based software development processes are employed to create software that is correct by design, and statistical usage testing processes are employed to provide inferences about software reliability.

• This systematic process of assessing and controlling software quality during development permits certification of software fitness for use at delivery.

Agile• Group of software

development methods• Based on iterative and

incremental development• Most important phrases

• self-organizing, cross-functional teams

• adaptive planning, • evolutionary development and

delivery, • a time-boxed iterative

approach,• rapid and flexible response to

change. • A conceptual framework• The Agile Manifesto in 2001.

Scrum

• Scrum is an iterative and incremental agile software development framework

• A flexible, holistic product development strategy

• Development team works as an atomic unit

• Opposing to sequential approach

Scrum

• Cross-functional teams

• Verification inside the teams

• System test is usually out of the team responsibility

• Competence problems• Small projects problem• Component test• Function test• Early system test

Lean (Kanban)

• A translation of lean manufacturing principles and practices

• Toyota Production System,

• Today part of Agile community.

Lean Principles

1. Eliminate waste

2. Amplify learning

3. Decide as late as possible

4. Deliver as fast as possible

5. Empower the team

6. Build integrity in

7. See the whole

Extreme Programming (XP)• Improve software quality and responsiveness to changing customer requirements

• A type of agile software development

• Frequent "releases" in short development cycles

• Introduce checkpoints where new customer requirements can be adopted.

XP Concepts (examples only)

• Pair programming• Planning game• Test-driven development

• Continuous integration

DSDM• An agile project delivery framework,

primarily • DSDM fixes cost, quality and time at

the outset and uses the MoSCoW prioritization of scope

• Pareto principle

• M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

• S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

• C - COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

• W - WOULD: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

Test-driven development (TDD)• Relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

• Test-first programming concept of extreme programming in the beginning

• Today standalone methodology

Feature-driven development (FDD)

• Iterative and incremental development process.

• An Agile method• Driven from a client-valued functionality (feature) perspective

• Mostly part of other methodologies

• What is needed for the customer most:• GUI?

• Perception of the quality of a SW by customers?

Rational Unified Process (RUP)• An iterative software development process framework created by the Rational Software Corporation (IBM)

• Not a concrete prescriptive process, but an adaptable framework, intended to be tailored by the development organizations

• Expected to select elements of the process that are appropriate

V-model

• The V-model is an extension of the waterfall model.

• Show the relationships between development phases and test phases

• Time and project completeness vs. level of abstraction

V-model, complex

Dual V-model• Describes a model of

complex development• For example:

• Hardware• Platform• Application software

• Development of a system's architecture is the “big V”• Components’/entities’

developments are the “small V”-s

• It shows interactions and sequences of developing a complex system and a system of systems.

Shouldn’t forget

CONCEPTSNeed to be understood

List of Concepts

• Practice• CI• Automated testing• LSV concept• Version control• Flow approach -- swedish hospital pres

• UML

• Design Patterns• Testing phases• code coverage• code review• defect backlog• static code analysis• unit test coverage• SQR

SOFTWARE DEVELOPMENT FLOW

System Development Lifecycle

Project planning, feasibility study

Systems analysis, requirements

definition

Systems designImplementation,software design

Integrationand testing

Acceptance,installation,deployment

Maintenance

SDLC

SDLC – Close to Reality

• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.

• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.

• Implementation: The real code is written here.

SDLC

• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.

• Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

SDLC

• http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle

• Waterfall might be useful in case of well determined req.-s and plans, but extreme could be better for less well defined requirements and prject plans

• Requirements• Specification• Architecture• Construction• Design• Testing• Debugging• Deployment• Maintenance

Activities and Steps

• Processes and regular activities (loops) always need additional efforts/people (cost)

• Means expensive…• But quality is a “must”…

• Or “good enough” quality?

• Processes• Good designer, bad designer

• Prepare for average designers

• No need for process if SW developed by one person

• Quality is far less a question indeed if someone knows the whole software alone

Problem of Processes

• RUP• XP• Agile• Lean• Dual Vee Model• TDD• FDD

• Waterfall• Prototype model• Incremental• Iterative• V-Model• Spiral• Scrum• Cleanroom• RAD• DSDM

Methodologies

coding for "real life" safe coding considering software industry expectations in...

Documents