Category: Management & Leadership

Simplicity Prevails

We engineers are masters of self-deception when it comes to our aptitudes to handle complexity. We believe we are way better at handling complexity than we actually are. In practice the level of complexity that people can master (me including) is disappointing low.

Instead of self-deceiving ourselves, we should embrace our limitations and aim for simplicity. This is what all geniuses of our time have been preaching for. Simplicity prevails.

“Simplicity is the ultimate sophistication.” — Leonardo da Vinci

It is common for tools to be too complex. We all know that only a tiny fraction of the features of Word are used, still the usual trend for a product is towards adding more and more features. Often, the best thing for a product is taking something away from it. Only simple tools prevail.

One problem with simplicity is that it is often confused with easiness or triviality. Easiness and triviallity are subjective properties relative to a user. They refer to the sense of familiarity or ordinarity. Simplicity is an objective property that refers to purity, the absence of mixing distinct elements.

Let us look at some simple features that are clear wins.

Using Venn Diagrams for Access Control

Have you ever been confused by the security settings of an application, not knowing what would be accessible or not to other users? Venn diagrams are simple and can be used to make an interface intuitive. Win!

Using Pictures instead of Texts to Log

Have you ever found yourself overwhelmed by the difficutly to compare tens of print statements to understand state mutations over time? Comparing texts is hard; comparing images is easy. Using a visual log is simple and supports better debugging. Win!

Using Examples to Test Programs

To test your code you exercise it with chosen inputs that serve as examples? Well, you could have invented unit testing. As Fowler says: “Kent’s framework had a nice combination of absurd simplicity and just the right features for me”. Win!

Using Live Code instead of Static Code to Understand Programs

Have you ever felts exhausted trying to mentally run code in your head when inspecting static sources? The underlying question is: what prevented you from runinng it and see it live? Finding a suitable unit test and breaking at the start of the method you are inspecting can be automated to become a one-click operation. Win!

Optionless search

Have you ever been repelled by the sheer amount of options in a search form? For instance this one. That’s tackling the problem of search wrongly. Google, Airbnb, and Facebook got it right, offering essentially one unique text input and hiding the magic of relevance matching. Win!

These examples show what I consider to be the level of complexity we can handle, and should aim at. These features are so simple to use they will immediately look easy and trivial. This is a good thing.

Scrum Wall vs. Issue Tracker

Last year, Mascha Kurpicz and I conducted interviews and ran a survey to better understand the dynamics of Scrum teams and their use of tools to support agile development. We wrote a paper. Sadly, it was rejected at XP 2012, mostly due to a lack of data to support our claims. Here is the abstract:

Scrum is a lightweight iterative process that favors interac- tion between team members. Software development is however a complex activity and there exist many software tools aimed at supporting it. This research studies the role of software tools within Scrum practices. It focuses more specifically on comparing the strengths and weaknesses of the Scrum Wall and issue trackers, as they are frequently used together within projects. This paper presents findings from interviews that have been further validated with a survey. Results show that the Scrum Wall is highly appreciated by Scrum practitioners. It encourages positive dynamics and supports well most of the work organization. People tend to consider software tools as impediments, but use them nevertheless to control information that would otherwise remain tacit. Synchronizing information across tools is reported to be a source of troubles.

I think there are several interesting findings in our study. Team productivity and team dynamics are challenging issues to understand, but very fascinating.

Thoughts About Scrum

Since now more than a decade, lightweight methodologies and processes have flourished under the umbrella of the Agile movement.

Despite the claimed success of Agile from daily practitioners, I haven’t seen many researches showing evidence that the Agile concepts really worked as expected; by this, I mean that Agile could still lead to reproducible success, but for other reasons that the one pushed by the various methodologies.

Here are a few open questions, especially about Scrum, for which I couldn’t find a decent answer. (For other related digression of mine, see real-world software development methodologies and What is a feature?)

Wasting time and unnecessary pressure

Scrum is organized around the notion of product backlog. One central notion in Scrum is that once started, the priorities of the current iteration won’t change; developers can focus and organize their work according to what’s been decided to go in the iteration, without being constantly disturbed by changes.

When a necessary change is detected, we tend to perceive it as highly prioritary: “We absolutely need this and that as soon as possible”. The existence of the product backlog and the frozen iteration improves this situation. Any story can be added anytime to the backlog. The priority of all stories will be reconsidered together when the next iteration starts. The process itself then promotes some relativity in the decisions that are taken, which is welcome as to lower the unnecessary pressure that is frequently generated.

Even though I heard this from a Scrum practitionner, I never found any evidence of this. It would however be possible to mine product backlogs to verify whether the priority of the stories tend to follow the scheme mentioned above: most of them are first entered with high priority, which then lowers over time. Only few stories are really prioritary, and the process helps their selection and identification (we could say the the signal-to-noise ratio is improved).

Delivering added-value

Another pillar of agile methodologies is to move away from technology engineering to product engineering. The team should focus on what brings most added-value – what make the software valuable – instead of what constitutes the software technically.

We see this tendency in several concepts:

  • Scrum has a user story, which is the expression of a valuable feature from the point of view of the end-user.
  • FDD has features, expressed in the form “<action> <result> <object>” (e.g. Calculate the total of a sale), which directly represents the value of the feature as perceived by the end-user.
  • TDD is less clear about this (and I’m not even sure if it’s considered as agile). Still, a test case can be perceived as the expression of a comprehensive feature.

While nice on paper, it’s not always easy to organize the development according to only added-value as perceived in the final product by the end-user.

For instance, the possible asymmetry between the complexity of the user story vs. the complexity in term of development effort, may impose a user story to be broken down into technology-related tasks.

The internal development tasks also escape the added-value scheme. A refactoring has no added-value from the customer point of view. How is then internal development effort managed in the context of agile methodologies?

I never found any clear positioning of agile practitioners regarding such problems. An analysis of existing backlog or issue trackers would be valuable to provide an explanation about how people manage this.

The case of bugs

Shipping a software product with no bug is an illusion. Bug reports,  bug triage and then bug fixing is part of the software development process.

Bugs and defects do however not fit very well with most agile methodologies. Should the user story or feature be reopened when a bug is reported? Should the bug be wrapped in a new story or features?

There isn’t lots of description of how the main development effort and the bug handling fit next to each other.
A study of how this happens in practice, both from point of view of the process but also from point of view of the tools (e.g. do most company still have an issue tracker to let customer report defects) would be interesting.

How agile are you?

The central point to agile, is well, to be agile. That is, to be able to adapt rapidely to changing requirements or situations. This stems from the fact that we can not anticipate everything, and that we can actually only anticipate very little when it comes to software development. And it’s a lot more rewarding and effective to improve the ability to face  changes than to desperately attempt to improve our ability to predict the future.

That said, there is no metrics for the “agility” of a team. It would however be interesting to define such a metrics (even if not a really tangible one) to be able to track progress in term of agility. Such a metric could be based on a mathematical model of how long user stories remain in the backlog.

Conclusion

Despite the wide acceptance of agile methodologies and the apparent success of these one, how they are really used in practice remains vague. It is especially hard to know how much the actual processes diverge in practice from the somehow theoretical vision of each methodology.  The methodologies do also not always address the whole spectrum of the software development lifecycle, in which case companies are probably introducing ad-hoc customizations and rules to cover their needs.

Getting Things Done 3.0

I started reading Getting Things Done, but then dropped it. I nevertheless quite enjoyed the points about (1) building an organizational system that we trust and (2) doing the action immediately if it takes less than 2 minutes (which I had heard many time before but didn’t know it came from this book).

The book is a bit old fashioned to me. We can argue that the concepts are general, but we are information worker now and the “basket” mentioned in the book have been replaced by web applications, USB keys, and iPhone.

Building then a modern organizational system that we trust is far from easy. We need to balance different dimension that impact our trust in a system, e.g. security, reliability, perennial data format, etc. Well, the usual non-functional requirements.

Ultimately, it’s a matter of time and risk: How long will I need to re-do the work? What are the consequence if I forget this or that?

In my previous job in an ECM company, I increased my awareness about such issues. Managing the massive amount of information produced nowadays is a challenge and business case. I remember I was astonished when I read these numbers for the first time:

Recent estimates show that a typical worker will take 12 minutes to process a single document. Nine of these 12 minutes are spent searching for, retrieving and refiling the document — meaning that only three minutes are spent actually using the information they’ve found.

The average office:
• Makes 19 copies of each document.
• Spends $20 on labor to file each document.
• Loses 1 out of 20 office documents.
• Spends $120 searching for every misfiled document.
• Spends $250 recreating each lost document.
• Spends $25,000 to fill a four-drawer file cabinet and $2,000 annually to maintain it.

The volume of paper documents that organizations must process has increased tenfold in the last five years. Increases in paper volume drive the cost of paper handling higher, which greatly reduces profit margins.

(from Document Management Overview.)

And for the story, I tried first to find this excerpt using a search for “Introduction to enterprise content management” on my hard drive. No result. I then decided to locate it manually. I went to Library > Intranet, communication & ECM and … it was there! It’s funny that even though I recalled what the book was about, the name “Document Management Overview” was completely different from what I tried. Ontology ftw!

Here is what composes my current organizational system:

Topic Decision Inception year
Email – Three mailboxes: one personal, one professional, and one for garbage.
– Redirection address @a3.epfl.ch as the default for long-lived communication (e.g. contact)
– BCC myself in email (2012)		 2004
Source code – < 2010 self-administered subversion, assembla.com for private projects
– 2010-2013 Google code
– 2013+ Github		 2005
Archival – Convertion of esoteric format (.eps,.pic) to PDF
– Recording of minidisc and super8 into .mp3 and .mov		 2005
Online CV – LinkedIn (since 2005)
– Stackoverflow (since 2010)
– Xing (since 2013)		 2005
Application and S/N – Store the serial number in the same location as the application 2006
Backup strategy  RAID drives is not enough if I delete files by mistake.
– incremental backup on CD/DVD
– complete backup on external HD
-TimeMachine since 2012		 2007
Digital music and picture – Not in the cloud
– iTune for digital music (since 2009)
– All pictures organized by date and periodic backup
– Gallery with Lightroom on personal website–
– DropBox for picture sharing (since 2010)		 2007
Information overload – In case of too much information piles up, I gargabe collect according to these rules. 2008
USB keys Be disciplined, copy the information on a computer asap and clear the key 2008
Agenda, birthdates and contact – Google Calendar
– Goolge Contact		 2008
Web identity and avatar – Avatar on gravatar
– Two usernames: ewernli and wrnli		 2008
Bookmark – Bookmarks are personal
– Usage of Foxmark with centralization on my server (not in the cloud)
– Organized in a taxomony / since 2013 with tags
– Pocket app (since 2017)
 2008
Place to visit, music to listen, movie to watch – Various Google Documents
-IMDB and Jini for movies (since 2013)
-Goodreads for books (since 2013)		 2009
Other To Do – Leverage Google Calendar for actions which have deadline
– iPhone Reminder App		 2009
Random thoughts – Twitter
– 2013 self-administered blog with Liferay
– WordPress blog (since 2013)		 2009
News and RSS – Google Reader
– Feedly		 2009
Scientific literature – Usage of BibDesk as master copy
– CiteULike (until 2017)
– Mendeley (since 2017)		 2009
Password and login – Password-protected excel spreadsheet 2011

Getting Things Done is to business what No Broken Window is to software development. Whenever something comes in that requires some action, either do it right now, or at least enter it in a reliable system for later (In the case of development, the system is of course the issue tracker).

More Links

 

Keep your desktop clean: a checklist

I found a post-it on my desk this morning that was actually there since several months (if not year). It’s a short checklist with questions to answer before deciding whether I will trash or retain a document.

I tend to retain too many documents (electronic and paper)  that consumes space and are useless — I will anyway never read them. This short post-it helps me in my cleaning activity. It helps me take some distance with the material and its importance.

  • is it hard to find the document again?
  • is the document important regarding legal aspects?
  • is the document up to date?
  • is the document currently/frequently used?

Then if all answers are “no”, trash it!

It’s amazing how many documents can actually be trashed according to this checklist. Free desktop again!