Some time ago, while researching types of defects and the cost of fixing them¹, I stumbled upon this:

Years ago I worked with a bunch of economists in the US Federal Government - they categorized ‘bugs’ in their memos into three types:

• Typos: Simple misspellings of words. Infrequent, easy to detect, easy to fix.

• Writos: Incoherent sentences. More frequent, hard to detect, harder to fix.

• Thinkos: Conceptually bonkers. Very frequent, subtle and hard to detect; almost impossible to fix.

Most ‘late’ bugs that I’ve seen in software projects belong in the last category - a lack of design or the failure to make a working mock-up leads to ‘thinkos’ which are only obvious when the application is nearly completed. These are expensive to fix.

Source: http://developers.slashdot.org/story/03/10/21/0141215/software-defects---do-late-bugs-really-cost-more

I would also add a new category to this:

• Ethos: Morally wrong, although possibly legal. These may take different forms: vary from a company to the next one, from society to society, etc. Even harder to fix than ‘thinkos’, as there is a reason (mainly economic) to keep them in place.

On a technical note, these are not usually well-known artifacts in the company, therefore not everyone should know about them. Only a few developers know the correct reasons behind them and the rest might be sold a fake reason, so the latter cannot fix these ‘ethos’, as they assume they are present for a good reason

At a client, today we’ve done a brown-bag session on refactoring: we’ve gone through and a live demo, including refactoring a core piece of our code.

We’ve done some mob programming to help identify some smells and how to fix them.

Update: I’ve grouped all small posts related to the self-study from June 2015 into a single post

Le monitoring de flux par l’exemple

I’ve read this article about monitoring, in the way of “by example”, by Cédrick Lunven and Julien Kirch (French)

The First Micro-service Architecture

I’ve read this article about microservices and how they were implemented many years ago by Robert C. Martin

How I Learned to Balance My Life With Remote Work

I’ve read this article about balancing life and work, either physical or remote by Michael Erasmus

Demystified CQRS

I’ve read this article about CQRS by Nino Martincevic

The perils of programmer education in the bazaar

I’ve read this article by Gregory Brown

6 useful and lesser-known git commands

I’ve read this article about git commands (log, checkout, stash, cherry-pick, annotate) by Jon Cairns

Is Your Scrum Standup Slowing You Down?

I’ve read this article by M. David Green

Me duele Indra

I’ve read this Bonilista (Spanish) by David Bonilla

TDD, BDD, [add every other method that promises software quality here] and the tea tasting lady

I’ve read this article by Rui Figueiredo about the scientific method, TDD / BDD and how to scientifically detect if the ‘how’ affects the result. In this case, exemplified by how to prepare your tea

The Art of Metaprogramming in Java

I’ve read these slides by Abdelmonaim Remani

When TDD does not work

I’ve read this article by Uncle Bob on situations where TDD might not be appropiate, especially around the borders

Mi primera semana como aprendiz

I’ve read Ronny Ancorini’s experiences in his first week as apprentince with Carlos Blé & Associates (Spanish)

Refactoring without good tests

I’ve read this article by Peter Bell on how to deal with a legacy codebase, what are the effects of not having tests and how to deal with. How to add tests to a codebase that is not ready for it.

Big Ball of Mud

I’ve read this paper, containing a collection of patterns and antipatterns (disguised as notes) by Brian Foote and Joseph Yoder

Comparision of different concurrency models: Actors, CSP, Disruptor and Threads [sic]

I’ve read this comparison of concurrency models by Rüdiger Möller

5 Whys

I’ve read this wikipedia article on the technique called “5 Whys”

Expectations, Outcomes, and Challenges of Modern Code Review

I’ve read this paper, direct link, by Alberto Bacchelli and Christian Bird on code review at Microsoft.

They explain how they do it, the exact methodology they are using and why they do it.

The main reasons to code review are:

• finding defects
• code improvement
• alternative solutions
• knowledge transfer
• team awareness and transparency
• also:
  • improve development process
  • avoid build breaks
  • share code ownership
  • track rationale
  • team assessment

The quality wheel

I’ve read this article by Jessica Kerr about the qualities of beautiful code

5 Minute Physics

I’ve watched this video on interactions with the mobile devices and related to physics by David DeSandro

Rise of the Transpilers

I’ve watched this video on the rise of the transpilers and coffeescript by Jeremy Ashkenas

Drawing Lines with Bresenham’s Line Algorithm

I’ve watched this video about how to apply the Bresenham’s algorithm to draw lines (implemented in pseudo-code and javascript) by Jenn Schiffer

Working with Minified JavaScript

I’ve watched this video by John Crepezzi on how to mix javascript files (clients and yours), how to decompile javascript in chrome, dev & debug tools

How we ran our Legacy Code Retreat

I’ve read this article by Andreas Leidig, looking for inspiration on running a legacy code retreat / brown-bag session. The experience report is here

Shift Left: Testing Earlier in Development

I’ve read this article by Rebecca Wirfs-Brock

Polymorphic Equality

I’ve read this article on implementing polymorphic equality on C#, by Carlos Blé

Commit messages are not titles

I’ve read this article on git commit messages and how to use them, by antirez

Oracle Considers G1 Garbage Collector for Java 9

I’ve read this press article on the G1 and CMS collector, by John K. Waters

What Tech Newbies Need

I’ve read this set of tweets, grouped by Jessica Rose about the most helpful things beginners can do to improve their programming skills.

JavaScript For Cats

I’ve read this introductory guide to javascript by Max Ogden

Why Doesn’t Python Have Switch/Case?

I’ve read this article on the switch case in the python language by Daniel Roy Greenfeld

[Joseph Moniz’s] Notes on Clojure

I’ve read Joseph Moniz’s Notes on Clojure.

Chemical Computing with Clojure

I’ve read an article on performing abstract computations with chemicals, written in Clojure by Carin Meier

Lenses

I’ve read this tutorial on writing lenses for haskell, a way of importing imperative getters / setters to a Data. Written by Gabriel Gonzalez.

On another note, the first part, about writing getters and setters in the naive way, is also explained in Learn you a Haskell > Chapter 8 Making Our Own Types and Typeclasses > Record syntax

Microservices in Haskell

I’ve read these notes on implementing a microservice in haskell, by AlexanderAA

Overcoming Resistance to Change - Isn’t It Obvious?

I’ve watched this video in the channel of The World with Theory of Constraints

Bacon is bad for you

I’ve read these slides on professionalism and the programmer culture, by Garann Means

Code is a job

I’ve read these slides, that are the continuation of “Bacon is bad for you”, by the same author, Garann Means

The Great Newline Schism

I’ve read this article by Jeff Atwood on the difference in newline character(s)

Top ten reasons why I won’t use your open source project

I’ve read this article on what’s necessary for an open-source project to be usable by others. Written by Adam Stacoviak

At a client, I’ve presented today an internal training on “BPM: Process and tools for developers”

In it, we have introduced the BPM concept and the main ideas in Activiti BPM.

Also techniques for hotswapping processes, tips and how-tos.

This category is mainly dedicated to anything related or included in the book ‘Practical Object-Oriented Design in Ruby’, by Sandi Metz

Note: This has been created a posteriori with a previous date

At a client, we’ve done today an internal training on “QA & how to test”. In it, the most skilled person with the QA role in the dev team has explained to us some techniques and concepts for testing

My notes

Verification vs validation: building the product right vs building the right product.

Principles

Extracted from ISTQB:

• testing shows presence of defects
• exhaustive testing is impossible
• early testing is better than later testing
• defect clustering: areas with bigger defect ratio or more critical, etc should be tested more thoroughly
• pesticide paradox
• testing is context-dependent
• absence of errors fallacy: the absence of defects does not imply perfect software. There are also problems with validation.

Techniques

People-based

• bug bashes: e.g., time-constrained
• subject-matter expert testing
• eat your own dogfood
• others

Activity-based

• regression
• scripted (manual)
• smoke
• exploratory
• installation
• load
• long sequence
• performance

Coverage-based

• menu tour: exploration based on menus (especially on websites)
• functional and system testing
• integration
• logic
• state-based

Requirements-based

• Equivalence partitioning: examples in the same set are considered equivalent
• Boundary based: there are interesting examples around and on the boundaries
• Decision tables: truth table
• State transition tables: state diagram

Risk-based

• make a prioritized list: probability and impact
• perform testing exploring each risk
• after a risk disappears, another opens. Adjust your test effort to stay focused on the current crop

Use case tests

• use case: a common case that represents one of your customer’s cases
• use busines language

Structure-based

• test coverage is different than code coverage
• test coverage is based on decision tables

Defining testing priorities

• customer and contractual requirements
• regulatory
• experience-based
• “Best representative”