C is dead, long live C

Last week I visited ACCU2012 conference at Oxford:

ACCU is an organisation of programmers who care about professionalism in programming and are dedicated to raising the standard of programming

Me and my colleague, Henrik Taubert, had our presentation already on the first day and therefore had also an opportunity to share, discuss and reflect with other people with various topics (380 altogether). We had a nice 90 min slot and again it turned out to be too short for our wide topic. I have experienced that 45 to 60 minutes should be enough in most of the cases for a “traditional” presentation. If you have an important message it must be able to be narrowed down into short and informative form. Too wide approach into interesting topic can even ruin the whole session.

Uncle Bob Martin had keynote entitled “Requiem for C” and the picture above is taken later in the evening… The ones who were there know what it is all about 🙂 Anyway, keynotes were recorded and will be available later from the  ACCU pages. (There is also a short summary below).

All in all I enjoyed my days there (although due to crappy WiFi I was not able to get anything meaningful work done….). If you have a chance to participate in the future, I recommend to do so.

Here are also some private notes from the sessions (thanks Lauri Mikkola).

Tim Lister: From Adrenaline Junkies to Template Zombies

–          Projects are as humans, humans have habits vs. project follow patterns
–          Only mathematicians and physics learn by concept, others by example
–          Safety value – pressure release (activity) for the team
–          Manana – the loss of “natural” sense of urgency (if the target is too far away in the   future)

  • Manana window, eg. 90 days is common for most people
  • The person with the longest view should be the CEO
    –          Lessons unlearned
  • Retrospectives rarely trigger change (for the people/organization not participating in the retro.)
    –          Project sluts
  • Managers who just can’t say “no”
    –          Dead Fish – pattern
  • From day one the project has no chance of meeting it’s goal, most people on project know this but doesn’t say nothing.
  • Hoping vs. estimating

–          The joy of success let’s you

  • Try harder
  • learn
  • experiment
  • have pride

–          Bottom line: Avoid the Dead Fish! Understand your bad patterns and habits (in the organization)

Real Team / Is Scrum Incompatible with your brain – Henrik Berglund

–          Presentations found here: http://www.slideshare.net/henrik_berglund
–          Individual goals exercise

  • “After this team effort, I have <done something fulfilling for me>” stickers before new sprint start
  • Good exercise for the team to set personal development/interest goals for the spring (task division)
    –          Storyline exercise (similar to Lyssa Adkins)
  • Presented to everyone on flipchart
    • Stickers from others on “positive” things about the person.
      –          Responsibility
  • Don’t say “I have to” or “must”  – take the responsibility and say “I want to” or “I don’t want to” instead
    –          Retrospectives
  • don’t solve the problem there
  • don’t list the problems
  • instead focus on : what do we want do/change, how to get there.. (?)

–          People don’t like other people’s ideas, they  like their own ideas 4 times more.
–          Things to try out: Exercises listed above and using of “responsible” arguments in expressing “want”

The Congruent Programmer – Phil Nash

–          Remember to keep your neck and head straight 😉
–          Check on Youtube: Bret Victor – Inventing on principle

Making Jenkins Better – Jez Higgins

–          Bottom line: Writing plugins for Jenkins are (should be) like writing makefiles
–          Maven is used to write Jenkins plugins

  • You need the Jenkins plugin for Maven to write Jenkins plugins

–          Thing to explore further: Jira plugin for Jenkins to automatically create release notes (for LLV/LSV) based on delivered content in the Builds.
–          AoB to Remember: Git hook for A-style code formatting (to be check if file formatting can be done without changing author details / loosing history)

Lean Quality Assurance: Much more cost effective quality assurance methods than testing – Tom Gilb

–          Software engineering is no “engineering” without measurable metrics
–          By building in quality, inspecting, reviewing, etc. you can catch up to 95% of the bugs
–          With (automated) tests  (according to Gilbs statistics data) you usually only catch around 15% of the bugs that are found/in the system
–          Everything can be composed down into quality metrics, even music and love
–          People with titles like Quality “managers/coordinators/etc” seldom have to do with quality but only with test. (should not be titled with the word quality)
–          Quality is not only about test
–          Quality Assurance does not include test
–          You cannot state that you are a “expert” in a “subject or craft” if you cannot quantify the “thing you do” to some measurable metrics
–          Further info: 750Mb of slides and PDF available
–          Thinks to explore further: What team/organization efforts could be quantified and measured, that could bring value to improve the development flow

Parallel Architectures – Detlef Vollman

 –          Hardware
–          History: From serial instruction execution to  pipelines..
–          SIMD: Single instruction, multiple data
–          SMT: Simultaneous Multithreading

  • doubled (multiplied) resources inside a single core
  • Exploits unused slots inside pipeline

–          Caches

  • memory hierarchy
  •  Always reads the whole cachline   CPU <- L2  (2-3cycles)<-L3 (5cycles) <- MEM (100 cycles)

–          SMP

  • Shared memory  eg. The caches of two CPUs access the central memory

–          Multicore

  • The Core data and instruction registers access share L2&L3 memory

–          NUMA

  • Non-uniform Memory access
  • Single address space
  • Access to remote memory via the other CPU .    MEM<->CPU<- – ->CPU<->MEM

–          Cluster

  • Independent computers connected by high speed network.  Connections between machines on MEM bus?

–          Grid ~ Cloud

  • Cluster with low bandwidth network, high latency
  • Locally distribute
  • Remotely distributed (e.g. SETI@home)

–          Cell

  • 1 PowerPC core, local storage
  • 8 SPEs
    • SIMD CPUs
    • 256kb local memory

–          GPUs

  • Typical SIMD CPUs
  • AMD ATI xx  , 160 SIMD cores

–          INTEL Many Independent Cores (MIC)

  • 32, >50 cores
  • Pentium core + SIMD cores
  • coherent caches
  • Will not really scale (due to memory constraints)

–          MPPA – Massively Parallel Processor Array

  • Ambric AM2043
    • 336DSPs

–          Keppler (Nvidia)

  • 512 SIMD cores

–          SOFTWARE

  • Memory Manager Unit
    • Maps physical memory address to logical
    • enables any kind of NUMA
    • Multitasking support
  • Transactional Memory
    • Grouping of memory addresses
    • No supporting HW yet
  • Memory bottleneck
    • Compiler makes huge difference
    • how memories are organized makes difference vs. computing power
    • “varying slice size” makes the difference, smaller size fits into smaller (faster) cache
  • Process
    • Inter process communication (IPC)
    • shared memory
  • Threads
    • “lightweight process” [common address space]
  • Co-operational multitasking
    • task explicitly release process
    • Scheduling by program
    • con: responsiveness
    • pro: no bugs, easy location interrupt
  • Preemption multitasking
    • scheduling by OS
    • pro: leveraging parallellsim, response
    • con: complexity (invisible flow control)
  • Lock/mutex
    • deadlock, fair scheduling, priority incersion (high priority task waits for low)
    • double check locking (2 x mutex)
  • “Multithreading is just one damn thing, before, after or simultaneously
  • Atomics
    • Provides transactional operation with memory synchronization
      • cache coherency
      • not composable
      • not for modifying multiple memory locations
  • Work stealing
    • load balancing for SMD
  • Transactional Memory
    • no hardware to support
    • Proven to works with SW
    • composable atomics
    • shared memory synchronization protocol
  • Parallel APIs
    • open MP

–          Bottom line:  Efficient usage of the new multiplying (parallel) HW architectures leads into “complex” memory management and scheduling problems on the SW side.

Requiem for C – Robert C. Martin
–          You got to let go of the hardware control, multicore and multiprocessor architecture evolves whit such a speed, that the programmers (and programs) cannot follow nor understand the HW anymore
–          Clock frequencies of single processors have reached their peak, and the processing power scales now only with the multiplicity of the cores
–           C & C++ are (still) to HW dependent, let alone assembly. Program performance written in them don’t scale on future and current multicore systems
–          Languages which abstract the HW is the future.
–          Bottom line: C is dead.

Devops, Infrastructure-as-Code and Continuous Deployment – Gavin Heavyside

–          Infrastructure as code

  • repeatability
  • automation
  • agility
  • scalability
  • reassurance
  • disaster recovery

–          Chef

  • Written in ruby, open source  configuration management for managing web server application

–          Puppies

  •  Similar as chef but more generic for managing continuous deployment for other systems as well (?)

–          Bottom line: Introduction of (industry standard)  SW tools for automating continuous deployment and management for web server applications

–          Bottom line by Borat: devops is about scripting and shit

Solid Deconstruction – Kevlin Henney 

–          SOLID ( http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 )

  • Single Responsibility Principle (SRP)
  • Open / closed Principle
  • Liskov’s substituin principle
  • Interface Segregation Principle
  • Dependency inversion principle

–          FLUID  ( http://www.slideshare.net/anoras/ndc-2011-the-fluid-principles)

  • Functional
  • Loose
  • Unit testable
  • Introspective
  • Depotent

–          Cohesion

  • All peace’s  seem to belong together tightly and pulling them apart would be unethical

–          SRP (in detail)

  • That a subsystem, module, class or even a function should not have more than one reason to change
  • Prefer cohesion. Gather together those thing that change for the same reason, and separate those that change for different reasons
  • The dependency should be on the interface, the whole interface and nothing but the interface

–          Looking closely Open/ close equals pretty much to Liskov’s principle due to

–          Bottom line: If you reach for the banana but get the whole gorilla, then you haven’t followed the FLUID principle

–          To take home:  Coach developers to get interested to learn about the consequences of SOLID and FUILD

About Henri Kivioja

I believe in teams, personal development, humanity and good life.
This entry was posted in Agile Skills, All and tagged , , , , . Bookmark the permalink.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s