CodeCraftConf take-aways

I’ll let the other guides at CodeCraftConf summarise their talks if they wish, but here’s a few quick takeaways that I want to record.

Simplicity

Simplicity is always good to strive for, but the most interesting question for me is how to tell when code is not simple enough.

It happens when we get frustrated, and swear, when we start to experience cognitive drag when trying to understand what it does.

Cloud

Nothing is secure (just ask anyone who’s filled out the PCI compliance questionnaire)

Lean coffee

Alignment is the most important thing to get out of meetings.

2 backlogs – how do we capture the idea that not everything on the backlog is equal? Maybe you need a “ready to start” definition as well as a “definition of done. Maybe you need a “we’ll definitely complete this sprint” vs “we’ll look at these next”, or maybe you just need to read Warren Buffet talking about focus.

 

CitizenM is a big improvement over last year in terms of noise levels.

Advertisements

3 thoughts on “CodeCraftConf take-aways

  1. “Make things as simple as possible, but no simpler” – attributed to Albert Einstein, although there is not record of him making this exact statement, it is acknowledged as a sentiment of his….

    In most scenarios, there is some degree of complexity [remember, complexity is actually a set of mathematical calculations] that is inherent. Occasionally this can be quite high. Attempting to avoid it will almost certainly cause negative effects.

    A very useful technique is to establish a set of boundaries (or a box, if you like) and be diligent about keeping as much as possible of the complexity within this box, offering up a simple(r) façade to the larger environment.

    Liked by 1 person

    1. I definitely agree with the need to facade complexity, whether it’s logic complexity or code/design complexity, but it’s important to distinguish between irreducable complexity due to the domain, and complexity that can be refactored and simplified by making different decisions.

      Like

      1. 100% agreement with the intent of your post. Much of my point deals with the pure meaning of complexity as a mathematic equation based on the number of node and number of interconnects as the primary.

        As a result, the result of said equations vary wildly depending on where you set our measurements. Lets us any “object oriented” language as an example. The common measuring points are either classes or methods at the tactical level, and assemblies at a higher level.

        An implementation with a single method in a single class that is thousands of lines long have a complexity measurement of 1.0 [unity], even though it is most likely incomprehensible and unmaintainable.

        Now refactor this into many classes, with many methods such that SOLID principles are applied. The code is much more maintainable and comprehensible [at least one should sincerely hope so]. Alas a mathematical complexity measurement of this could easily be in the hundred of thousands, or millions!!!

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s