Managing source code

Bogusz JELIŃSKI ?
Warsaw, Sep 17th, 2015
 ? the plot from the title slide
depicts cyclomatic complexity –
how software evolves with time

Agenda
• What is it all about?
• How to prevent the loss of code?
• What is actually source code?
• What does "good quality code" mean?
• Let's measure it!
• Metrics for coding standards
• Software process made hermetic
• Misleading alternatives for the process
encapsulation
• Skipped topics - there is much more behind
 What is it all about?
You should care because:
• code is a vital asset - it is the core of the digital
business
• not visible by business, but may become a huge
issue
• the knowledge how to use the code is a neglected
asset which vendors will use to blackmail you
• a pure product of human thought – millions of
lines, each can be written in a hundred ways, each
can be a mistake
• bugs can ruin security and performance. And they
will.
 How to prevent the loss of code?
• take care of legal aspects, it is not simple
• store the code in your own repository
• store every single line, do not neglect the smallest
systems
• make your software process hermetic (hints to be
presented)
• get rid of the human factor - automate! Or at least
supervise the process!
• review your code - use static analyzers!
 What is actually „source code”?
• any command in any language, interpreted or to be
compiled, affecting a system's behavior
• compilation sequence (yes!)
• resources needed for compilation or execution
• shell scripts used to compile, configure, run, manage
and monitor the system
• unit tests
• runtime configuration, especially when there is no
explicit configuration management. The boundary
between code and configuration is fuzzy these times (is
web.xml a code or a config item?)
What does "good quality code" mean?
Trait Description If neglected
up to date coherent with the production environment some functionalities missing

complete containing all the elements from the previous slide a blocker for development and
maintenance
compilable the software process (dynamic) perspective - should a blocker like above
compile if complete
fully merged no change/functionality forgotten for a release some functionalities missing

well tested had all expected functionalities been delivered before More issues on production likely
tests started? What does the Kan's integration pattern to appear
(see the next slide) look like?
coding ISO-9126-3 (replaced by ISO-25010) or other good Security or performance issues,
standards programming practices conformed with. code hard to maintain
obeyed
open-source One has to be sure that a software complies with open- It can restrict the use of
licenses source (BSD, ASL, …) and free software (GPL, LGPL) software. In the best case - you
obeyed licenses, as these licenses are unconsciously used by shall be forced to reveal your
developers. source-code.
low IT debt that metaphore of the coding standards has gained The interest is the cost of bug-
momentum lately fixing
code covered what proportion of code is being tested by tests such Higher risk of bugs
as unit tests?
 CAST health factors
Health Description Example business benefits
factor
Transferability It assesses how quickly a new team or member can understand and work with an • Reduces inefficiency in transferring application work
application. It provides the means to understand how easily applications can be between
moved between teams or team members including in-house and outsourced teams
development teams. • Reduces learning curves
• Reduces lock-in to suppliers
Changeability It measures the effort necessary to modify applications in order to implement • Improves business agility in responding to markets or
new features, correct errors, or change the applications' environment. Measuring customers
and monitoring changeability is especially important for mission-critical • Reduces cost of ownership by reducing modification
applications when change is driven by tight time-to-market schedules. effort
Robustness It shows what affects the stability of the application and assess the likelihood of • Improves availability of the business function or
introducing defects when modifying it. Robustness measures the level. service
Robustness also measures the level of effort that is required to test the • Reduces risk of loss due to operational malfunction
application, i.e. how easy it is to test it and check its behavior • Reduces cost of application ownership by reducing
rework
Performance / It measures the likelihood of potential performance bottlenecks and potential • Reduces risk of losing customers from poor service or
efficiency future scalability problems. response
• Improves productivity of those who use the
application
• Increases speed of making decisions and providing
information
• Improves ability to scale application to support
business growth
Security Attributes that affect an application’s ability to • Improves protection of competitive information-based
prevent unauthorized intrusions. Security measures the likelihood of potential assets
security breaches linked to coding practices and application source code. This • Reduces risk of loss in customer confidence or
represents risk analysis and provides prevention measures necessary to avoid financial damages
opening critical vulnerabilities and security issues that can damage the business • Improves compliance with security-related standards
and the entire company running the applications.
A bit more on „well tested" – the code
integration pattern
Stephen H. Kan, Metrics and Models in Software Quality Engineering 2nd ed,
pp. 242, Addison-Wesley, Boston (2004)

How much
code do
you deliver
during
tests ???

https://books.google.pl/books?id=EaefcL3pWJYC
 Let's measure it !
Or at least do something about it!

Trait Recommended actions / tools A metric example

up to date deploy from your own repository. Keep the code Binary: up-to-date if revision
location in the CMDB. Compare the revison date with date > release date – x days
the release date (automated reports)
complete Encapsulate the process - no deploy without the Use the maturity scale (see the
repository in the middle next slide)

compilable Use continuous integration Maturity scale

fully merged Numerous tools on the market to track requirements Binary: all feature branches
and their implementation merged to the integration one
well tested Measure the size of changes at particular milestones size of code comitted during
(eg svn diff) tests devided by the size of the
whole change/project
coding standards Use static analyzers – eg Sonar Eg Sonar’s Rules Compliance
obeyed Index
Open-source Use Palamida. Binary: scanned/not scanned
licenses obeyed
low IT debt Use static analyzers – eg Sonar Sonar’s Technical Debt

code coverage Again - Sonar Sonar’s Code Coverage

Source code management –
process maturity
 SCM process maturity cont.
Lv Short descr. Some more description Risks
0 Unknown Source code missing or managed by a vendor Possible loss of asset
location
1 Code on a Source code in a drawer, in a server, not in a May not be complete
CD-ROM repository under version control and up-to-date

2 Repository Known location stored in CMDB but unable to Knowledge may be

exists compile it - no knowledge or no tools and costly to regain
hardware
3 Repository Compilers are owned or managed by a vendor or Old versions of tools
used the compilation is an arduous process might be hard to get

4 Single build The build knowledge is stored in form of a Missing knowledge

script computer algorithm/sequence about configuration

5 Continuous Automated build Still missing

integration knowledge about the
deployment
6 Automated Getting rid of the human factor, the executable is „works on my
deployment distributed by a script/robot machine” might still
be heard
Encapsulation of the SCM process
No Step Description
1 Legal stuff The software vendor should be formally obliged to the provision of the complete
source code with an unequivocal documentation of compilation sequence and a
deployment procedure, most preferably a script, eg a Jenkins job
2 Repo feed After the construction phase the vendor should submit the code to the customer's
repository, by hand or by automated replication of the vendor's own repository. The
decision on which stages of the project the code is to be delivered depends on the
particular organization and situation
3 CMDB feed The vendor provides the address (location) of the source code. The location of each
version should be stored in a CMDB. This detail is important as there can be hundreds
of branches in the repository. There must be also a person indicated in CMDB as being
solely responsible for the source code of a system (location, quality, …).
4 Checkout The code submitted by the vendor, which location is stored, is checked out from the
repository under the supervision of a person who is loyal to the customer (if the
process is not automated).
5 Compilation The code gets compiled as described in the compilation procedure under the same
supervision; executables are produced.
6 Deployment The code is deployed to runtime environments under supervision or in an automated
way. The only executable allowed to be deployed is the one produced in step 5 (the
interpreted code checked out in step 4)
7 Next In further phases stabilization and maintenance fixes are delivered (and new change
requests, new functionalities) – the process iteratively returns to the step 2
iterations
 Misleading alternatives for the
process encapsulation
• performing (at certain intervals) a comparison
of code archive with the content of production
environments
• deploying the production environment from a
repository periodically or at the end of an
outsourcing contract, with extensive
regression tests
Why are the alternatives misleading
• such ad-hoc actions must be conducted or be supervised by a competent and loyal
third party, usually a highly paid consultant.
• due to the nature of technology it is not always possible to determine the conformity
of the object code (executables), even if they are formed from the same source code.
• the restoration of the production runtime environment from the repository is
generally not accepted by the business side because of the risk of downtime and
requires costly regression testing of the whole system.
• an efficient, repeatable process, subjected to self-optimization, in which people act
in a quasi-automatic, learned way, is usually much less expensive (and often even
unnoticed) than single audits, requiring escalations and interfering with the course of
other business processes in the company.
• postulated encapsulation techniques and tools do not imply the creation of any new
process or process instance, but only shift already functioning activities in terms of
supervision, roles and tools towards the customer. The resulting costs are already
incurred and included in the price, the customer pays for them (eg for the repository
storage for developers) as the vendor is not a charity organization. So the postulated
change is mainly about the loyalty of supervisors, ownership of tools and procedures
and their location.
 Skipped topics
• organization of work in the repository (eg regime of code
merges)
• code reuse to avoid duplication of functionalities and help
reduce the cost of system development
• measurement of size changes in a software (backfired
function points), verification of the actual cost of the
contractual changes,
• monitoring of code delivery and its impact onto work
efficiency (Hawthorne effect)
• which programming language to choose to reduce lock-in to
suppliers or meet expected performance goals?
• …
Thank you for your attention! 