Code Reviews and the "If it ain't broke, don't fix it" principle

"If it ain't broke, don't fix it." is credited to Bert Lance as the person who popularized it, when he was quoted saying it in the May 1977 issue of the magazine Nation's Business.The expression became widespread, and William Safire wrote that it "has become a source of inspiration to anti-activists." - Wikipedia

Sometimes this principle will be put in place while performing Code Reviews (CR is a verification measure that intends to spot software defects by reading the software source code, as early as possible in the software life cycle). This only means that the main reason you are reviewing the code is to spot defects, so optimizations, formatting issues are out of scope (even if they bother you, don't engage into unnecessary discussions with the author).

Unless, of course, they are part of the written coding conventions for the project (some projects will inherit whatever the company or the customer have). This means that indenting code at 2 spaces instead of 4 could be a defect if there is a coding convention for this team that requires this specific indentation.

Also sometimes, as input to a code review a check list (of different sizes ;) could be handed to you. And those check lists could cover more that spotting defects.

So this principle applies in principle for code reviews unless there is a good reason to break it (Software coding conventions, check lists that are input to each code review).

Got it?

TOOLS: Modelling Tools Hot Topics

The main (hot) topics for any modelling tool include:

- How to organize hierarchically information (eventually, segregate model info by SW life cycle phase plus, RFP, Proposal packages)
- UML Support: New packages, new subpackages; new [UML] diagrams; new [UML] elements; establish relationships between them (UML relationships, several types: agreggation, composition, generalization, simple trace, ...);
- How to store requirements information: features (requested, proposed), requirements (several types); features and requirements are not part of the initial UML spec so the tools will support them differently (with some kind of stereotyped UML element most probably); if applicable: How to store testing information (the spec as well as test results including evidences and created issues) - typically for this, test management tools will be used.

- How to create traceability matrices. How to export them (to Word, CSV / Excel, ...)

- How to perform traceability analysis (what relates to what; where is it stored in the model, ...), including gap analysis
- How to draw basic UML diagrams: Some are simpler than other: class, sequence, object, package, deployment, use case, state machine, activity, communication, composite structure, component, interaction overview, and timing diagrams (Tip: See "UML Distilled")
- How to capture sequence diagrams from executable code
- Team conventions for the model: package names, UML Element identifiers (requirements, UML components), ...

If you know how to do this in your UML Modelling tool then you're ready to start modelling.

Advanced tasks for team leaders might also include:
- How to generate documentation from the model (HTML, doc, xls, PDF, more)
- How to reverse engineer: Code, physical database models, Web Services, XML...
- How to forward engineer (classes to code skeletons; tables to DDL SQL, ...)

Additional tasks to be performed:
- How to create a collaborative (centralized) model from scratch
- How to baseline the model (per milestone) and perform backups
- How to activate and configure security (roles, users, authorization)
- How to activate and read audit logs (activity logs, per user)
- How to import and export from the model to other UML tools (XMI support) - either the full model or parts of it

If you know how to do these latter tasks, you're ready to help / manage teams doing modelling.

Modelling tools include Sparx Systems Enterprise Architect (EA), MagicDraw, ...
(Click here for EA additional documentation).

(@2016-07-26: Updated task grouping; minor rephrases/typos; 2016-11-17: EA add. doc. link)

RESOURCE: Code Smells and more (Design Patterns, Anti-Patterns and Refactoring Tips)

One interesting reference guide to design patterns (and anti-patterns) as well as "code smells" (who happen when the code you're touching smells like a rotten bird in your garden) is: 

• https://sourcemaking.com/design_patterns (Design Patterns: structural and more; also remember to avoid anti-patterns)
• https://sourcemaking.com/refactoring (code smells: what to do to improve this "code smell"?)

Nice readings. 

INDEX: The Agile/Scrum index of useful links

To gather some resources and information presented on this site (and mostly available in the internet) here it goes, the Agile/Scrum index of useful links (not exhaustive):

1. http://silvaonsoftware.blogspot.pt/2016/05/scrum-agile-main-documents-and-5-line.html (Resumo do SCRUM Official Guide: 16p. em 5 linhas ;)
2. http://silvaonsoftware.blogspot.pt/2016/07/book-sbok-guide-guide-to-scrum-body (Scrum Body of Knowledge)
3. http://silvaonsoftware.blogspot.pt/2016/04/resource-agile-videos.html (learning through videos)
4. http://silvaonsoftware.blogspot.pt/2016/06/book-actionable-agile-tools-jeff.html (BOOK with additional tools to use with Scrum, e.g. during some Scrum events)
5. http://silvaonsoftware.blogspot.pt/2016/04/quality-attributes-invest-on-proper.html (about the INVEST Model that each US shall respect)
6. http://silvaonsoftware.blogspot.com/2016/06/the-state-of-scrum-2015-report.html (The State of Scrum Report)

RESOURCE: Security is a Process

Security is a process: It is not just a tool to produce you reports on potential holes (when probably you don't have the time or the skilled persons to browse through the detailed report it generates).

And this is what happens when you don't have the process in place. You will get to the cover page in the news (for the bad reasons):
https://www.publico.pt/portugal/jornal/auditoria-detectou-21-falhas-de-seguranca-no-sistema-informatico-dos-tribunais-21474798

Excellent initiatives at this level (security) are government initiatives like these ones:

• https://en.wikipedia.org/wiki/Cyber_Essentials (UK)
• https://web.nvd.nist.gov/view/ncp/repository (US, from the NIST)
• https://nvd.nist.gov/ncp/repository (the checklists)
• http://www.usccu.us/documents/US-CCU%20Cyber-Security%20Check%20List%202007.pdf (2007, US)

Tools: (INTERNAL):

1. At the "SW and Security Product Assurance technical area" a list of recommended tools can be found and some are security-related: https://delivery.critical.pt/TechAreas/sspa/SitePages/Web%20Application%20Security%20Testing.aspx (accessible from https://delivery.critical.pt/TechAreas/sspa/SitePages/Tools.aspx)
2. Security Testing Tool Example: IBM AppScan: Used to perform automated web application security tests (dynamic). IBM Security AppScan Standard helps decrease the likelihood of web application attacks and costly data breaches by automating application security vulnerability testing. IBM Security AppScan Standard can be used to reduce risk by permitting you to test applications prior to deployment and for ongoing risk assessment in production environments. 

Remember: Your information system is as strong as its weakest link. For instance: If you don't patch your system components that you rely upon (e.g. your RDBMS, Application Servers, File Servers, Web Servers, target Operating Systems) who do you think your customer will turn to when a security flaw turns up?

History: 2017-11-30, updated with SSPA internal resources (and IBM Appscan tool).

Project Management: PMBOK

The PMBOK is an indispensable reference for Project Managers (the basis for certification of Project Managers at the Project Management Institute - PMI): 

• https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge

Citando: 
The PMBOK as described in the Guide is intended to be "subset of the project management body of knowledge that is generally recognized as a good practice. 'Generally recognized' means the knowledge and practices described are applicable to most projects most of the time and there is a consensus about their value and usefulness. 'Good practice' means there is a general agreement that the application of the knowledge, skills, tools, and techniques can enhance the chance of success over many projects."

Agile: Kan Ban (Getting Started)

Kan Ban is one of the Agile Methodologies, intimately related with the Toyota Production System (TPS), Lean Manufacturing and Just in Time (JIT) production concepts (started in the manufacturing industry):

Some interesting starting points include:

• Getting started: https://kanbanery.com/ebook/GettingStartedWithKanban.pdf
• Kan Ban vs. Scrum: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf 
• http://www.kuehne.com.br/Kanban.pdf (PT BR)