Innovation is not a Linear Phenomenon: The Faraday FF Zero 1 Example

Innovation ‘R’ Us

Every company is trying to “innovate” these days… no matter how large or small. Some of the bigger ones are virtually pleading with their multinational workforce through challenges, awards and incentives to come up with the magic pill that will help the company sail through stormy waters (As Alf Rehn summarized it [1], “in April we innovate, in May we fire people”) .

The smaller ones… well, there are companies based entirely on nothing else but “an innovative solution” to do something you could already do before (but this time in a Javascript framework). Looking at it from the Lean Startup perspective, I find it a bit weak when a whole business is based on the USP of “innovative”. Your solution could be based on quality attributes [2] that make it faster, scalable, interoperable, customizable, streamlined, or really 100 other ways that could maximize value… the means to achieve these better be innovative, because that’s the very least your customer expects from you!

Have you ever heard a Formula 1 driver call himself fast? Or a firefighter call him/herself brave? Or a surgeon boast about how precise she is? No, because these are attributes that are inherently expected of them. If they weren’t fast or brave or precise, they wouldn’t last very long in their line of work. Similarly, today all technology companies are expected to be innovative in order to survive. You know who boosts their own ego publicly? Pop stars:

 

Innovation is… Not Where You Think it is

Now, about Faraday. Earlier this year at CES I picked up this leaflet from the Faraday FF Zero 1 booth. Since then, I have thought often of the part marked in red below:

Faraday-3

“SVP of R&D … spotted a drawing of a racecar on a designer’s desk and thought …”

BOOM. Innovation happened. Did the designer have a mandate to come up with a supercar? No. Was the SVP in an in offsite innovation workshop, brainstorming with other employees? No. Was there an innovation competition or challenge going on in the company, with an award at the end of it? Probably not. This is possibly the best example that innovation does not happen in an institutionalized manner. When successful innovation happens, it comes from the most unexpected places, more often than not driven by synergy, and it opens up a non-linear value proposition:

innovation_graph2

Original image credit: [3]

 

An Indicator of Innovation

These days some people are solving more problems with a Raspberry Pi over a weekend, than during a whole week of work in front of a corporate laptop. What can leaders do to harness this immense creative potential? I think the answer is to build an organization conducive to innovation, geared up to quickly change course when an innovation potential appears on the horizon, and… basically get out of the way. Easier said than done, you say… there are risks, budgets, stakeholders, possibly even (shudder) committees… no way this is going to work.

Which brings me to the final point: how deeply is trust rooted in the company’s culture? In Faraday’s example, the SVP trusted that something produced by one of his designers was potentially a big deal. It did not come up through a chain of committees and approvals. It happened through synergy. And while structure can stifle synergy, trust can help it thrive.

I therefore argue that the amount of trust in a company is a solid indicator of innovation potential. How much employees trust the leadership’s direction, how much coworkers trust each other (even across borders and timezones) and how much the leadership believes in the people they hired: these factors determine how likely synergistic events will be recognized, and nurtured into products or solutions that are called “innovative” by customers and competition, not just by the companies themselves.


[1] Alf Rehn, “How to Save Innovation From Itself”. Craft Conf 2016 talk.

[2] George Fairbanks, “Just Enough Software Architecture: A Risk-Driven Approach”. InfoQ interview and excerpt.

[3] MintViz.

Advertisements

The Global Bullshit Crisis of 2015

doc_bullshit

For the first time in recorded history, the total amount of bullshit being produced on planet Earth every year has exceeded the amount of human shit produced annually.

Leaders around the world are rising up to the unprecedented challenge. “This will not be tolerated any more,” said the leader of a leading Muslim League. “It has come to r misr attention that Bullshit now needs freedom and democracy,” a prominent American leader added. Meanwhile Russia has announced a zero-tolerance policy towards Bullshit: “Any shit will be shot out of the sky. We can’t afford to wait any more to confirm if it is Bullshit or not.”

China, on the other hand, has taken a rather controversial stand by declaring that they will produce even more Bullshit cheaper and faster than anyone else. India went two steps ahead: demanding that Britain should pay reparations to India for all the Bullshit. The UK’s response was to put all Indians on the Bullshit Watch List. A scandal ensued when a leading tabloid revealed that 65% of Hindustanis in the UK are in fact from other -stans. “Bullshit!” was the response from the leaders from these other -stans.

African leaders condemned the event strongly: “Whenever the world discovers something new, it leads to decades of strife in Africa. We are still paying the price for being the cradle of all Human Bullshit.” Soon after, Japanse scientists shocked the world with their discovery that radioactive Bullshit has medicinal properties.

Meanwhile, all of Europe has united against Bullshit. “We must preserve our own Bullshit and not let it get diluted by Bullshit from outside,” said a spokesperson. Canada and Mexico were the only countries to not react. Allegedly when the Bullshit hit them, they were surprised to learn that “North America” is not the same as “America”. Australia reacted strongly by deporting a prominent Hollywood actor’s dogs and New Zeland declared that they need a new flag to deal with all this Bullshit.

The same actor then announced his new blockbuster about Bullshit, expected to complete production in 2017. Bollywood promised to copy the script, add songs and release a Hindi version by 2019. Kollywood vowed to copy the Hindi version and release it in less than 6 months. This chain reaction went on until Rajnikanth announced that he had already made a 3D version of the movie in 1972.

The rest of the entertainment industry was not far behind. The video game industry responded with tons of Bullshit Simulator apps and TV channels were flooded with inspiring shows like “Bullshit Idol”. The music industry announced that Bullshit Dance Music (BDM) tracks could be downloaded for free, in return for credit card details that would be “hacked” only a year later.

Owing to all this frenzied activity, the two leading news making agencies of the world decided to form a consortium aptly named the Bullshit Universal Reporting Platform (BURP). According to their official press release: “In this connected and informed world, our viewers don’t accept plain old Bullshit anymore. Fortunately, we have the backing of such large global corporations that we can afford to create our own Bullshit.”

Silicon Valley has taken up the digital baton to solve the problem from a tech standpoint, and failing that, make tons of money consulting about it. Oogle was the first: “People are searching for so much Bullshit these days, we had to split our company into two to keep up with the demand,” they claimed. Fakebook followed with a public beta of the new Bullshit Multiplier feature. “Throw any Bullshit at it, and it will display similar Bullshit that you might have otherwise missed out on in real life,” reads their updated website. Picosoft and Zamaon almost simultaneously announced their new OneShit feature. “Why should you be limited to your own Bullshit? We want to take Bullshit into the cloud, so you can access any Bullshit, anywhere, on any device.”

Halfapple, however, was ahead of everyone else as usual with their ground-breaking product offering: iShit. No one really understands what it does yet, but there is speculation that for its price, it can probably solve California’s drought problem.

The car industry was quick to recognize the potential of all this surplus Bullshit as well. “Our best researchers are working on it. By 2020 we expect to mass produce cars that run on pure Bullshit,” and industry spokesperson said.

The impact of this event has far reaching consequences for the human race as a whole. Space Agencies around the world are launching probes to other planets to find the origin of Bullshit. Studies have shown that the weight of all this Bullshit is slowing down the rotation of the Earth, and as a result we may soon lose the Moon. “Good riddance,” said the Director of the leading Space Agency. “We didn’t find water on it anyway.”

UFO researchers as well have chipped in from the fringes: “Not since 1947 have we witnessed so many confirmed sightings of Bullshit around the world.” Countries where these sightings have occurred in recent months have been quick to cash in on the tourism opportunity, complete with guided package tours in 12 languages.

Scrum, Kanban, Scrumban or Just Ban Scrum? (Part 2 of 2)

Part II: Some Solutions

Continued from Part 1, with the same disclaimer applied.

frAgile

 

Collaboration and Distributed Scrum

If you’ve been in a successful Scrum Team with geographically distributed members, I would really like to hear from you, O Venerable Master. After all, team effectiveness has been known to diminish with as much as 2 meters of physical separation. If you must do Distributed Scrum (hopefully as a transitory step), then here are a few tips that will (I hope) save you the trouble of learning the hard way:

  1. Obviously, ensure everyone on the team is fully aware of language and cultural differences, especially the Power Distance Index (if that sounds familiar, it’s from Malcolm Gladwell’s Outliers)
  2. Email is only 14-17% effective as a medium of communication (Videoconferencing helps)
  3. Further, information is lost exponentially as a function of distance and overhead of tools used (simply put, people are inherently lazy…)
  4. …Which may prevent you from achieving fully cross-functional teams without specialists
  5. Agile at scale requires trust at scale
  6. Everyone needs to have access to the same infrastructure (at the same latency) and an identical development environment
  7. Get Agile Evangelists (SM, Coaches, stakeholders) at every location and get them to agree on your organization’s Scrum process
  8. Eliminate mixed signals, possibly by having a Proxy Product Owner
  9. Empowerment and Autonomy are useless without Feedback
  10. Establish an Exchange Program where [at least some] developers from different locations get to experience the reality of their counterparts (This will probably be your best investment)

The most important consideration, given all the specific limitations of your situation, must be that whatever arrangement you come up with, is sustainable. Create success stories and replicate the model. And note that Distributed Team can very well exist without Distributed Scrum.

Why Are You Doing Scrum, Anyway?

One day I’m going to be an Anti-Agile Coach. Because I’m convinced they’re so many people getting it wrong, that there’s a lot of money to be made from it. But first, some free advice: You should really consider if Agile or Scrum is really applicable to your Organization, Industry and Business Context. A good starting point is the following thought process:

You would like to adopt Scrum (or Agile) because…

  1. …Your scope/specifications/customer commitments change often (If not, you might be indulging in WaterScrumFall)
  2. …Your market changes often, requiring quick adaptability (e.g. Competition pops up out of nowhere overnight)
  3. …You need to deliver (or release) continuously (As opposed to a one-time deployment, followed by maintenance)
  4. …Your technology stack can/will change often (i.e. you haven’t invested tons of $ in license fees, and/or you will evaluate multiple options)
  5. …You have the flexibility to experiment/take risks, and your organization rewards failure (or at the very least, doesn’t penalize it)
  6. …Your dev team is nascent, so you expect dev processes to evolve
  7. …Your industry is neither mission-critical nor heavily regulated (although there are exceptions as Nancy Van Schooenderwoert explains)
  8. …You have metrics to show that Scrum would be more effective
  9. …Your Admin/HR/IT teams have Daily Standups (yes, I have seen them happen)
  10. …Everyone else is doing it

If you scored low on the above checklist, please consider that Iterative Software Development is still a thing, especially if you’re dealing with hardware or manufacturing. It’s not Waterfall, but it’s Scrum with a bit more commitment.

On the other hand, you might be in a field of work where you’re ready to treat software development more like Surgery than Civil Engineering (as Dan North explains in his talk).

Whatever you do, don’t indulge in Reverse Waterfall: Convincing yourselves that what you delivered is in fact what you intended to deliver.

(Please share your thoughts and experiences as a comment or connect with me on Twitter: @survivalcrziest)

 

Scrum, Kanban, Scrumban or Just Ban Scrum? (Part 1 of 2)

Part I: Some Problems

I have been playing the Scrum Master role off and on since 2008, almost all of it for geographically distributed teams. During this period, I have been lucky enough to work for 3 different companies in 4 countries. Over the years, a sinking feeling has been growing within me that we have started using “Agility” to mask unwillingness (or I dare say, often, inability) to commit. Allow me to crystallize some of the thoughts that are forming in my head.

(My usual disclaimer applies: none of the below is intended to reflect on my employer(s) or specific colleagues, whether past or present. These are my personal, generalized opinions intended for retrospection.)

ScrumTF

Ceremonies and Metrics

First and foremost, if you don’t have Sprint Retrospectives, or in your organizational/business context, are unable to enforce accountability for, or effectively followup on, action items identified in the Retrospective, then read no further. Your Scrum is Doomed.

Sprint iteration size matters, too: “A 2-week sprint is just enough time for a mini-waterfall, and thus we are all basically whitewater rafting all the time” ( — Dan North).

If:

  • you’re not collecting metrics (at the very least: Capacity, Velocity, Committed vs Completed Story Points, Release Burn Up, possibly correlation between Story Points and Hours, if you’re organization is into that sort of thing, and various forms of Lead Time)
  • or not really paying attention to what they’re telling you
  • and they are not visible to and understood by the whole team

then you have already failed, you just can’t see it yet.

Demo vs Release

On the other end of the spectrum, when the mandate for Scrum or Agile comes top-down, often there is excessive emphasis on ceremonies. Specifically, the end-goal of the Sprint becomes the Demo, rather than the Release. Scrum clearly dictates that no additional or specific effort must be spent on the Demo, it should be more like a natural outcome.

You can have as many Demos as you want, but what really matters for a product is Customer Feedback. Which, just to be clear, is not the same as Internal Management Feedback. Management is inherently biased in favor of your team, after all they very likely played a big part in hiring and building it. 10 internal demos are worth a single demo in front of a potentially paying customer.

The focus, then, should be on the Release of the Potentially Shippable Product Increment (complete with changelog, user documentation, installers, troubleshooting guides and quality reports) rather than an orchestrated demo in a controlled environment. This is where Continuous Integration, Continuous Deployment and more recently, DevOps comes in to the picture. If your Release Process is time consuming, unpredictable, not automated and/or has too many dependencies that are not in your control, your team is not yet Agile.

Dependencies

If your software dev team is Agile, but the rest of the organization is not, Agile is going to fail. By rest of the organization, I mean other dev teams that they have dependencies on, manufacturing, HR, Admin, IT — every single department in the organization needs to understand, live and breathe Agile. Because if they can’t respond to change effectively, then they will hold your software dev team back.

The most effective way of crippling a self-organizing Agile team is to give them full accountability, with limited or no influence over those responsible for potential impediments.

Another assured path to mayhem is when multiple teams work on a shared codebase in concurrent sprints, or when a dependency is being iterated on in the same sprint as a feature that needs to be delivered.

The Bottomless Backlog

Often in geographically distributed teams, and/or on large scale projects, the physical Scrum Task Board is replaced by a more practical virtual one. Such task boards, like those provided by JIRA Agile, Rally, Trello and several others, replace Post-Its by virtual cards, enhanced by features such as attachments, comments, time tracking and reporting. Just like any other application of technology, there is a flip side: It just a matter of a few clicks and keystrokes to add something to your Product Backlog, or to alter project plans in a significant way by moving tasks around. It’s very easy to get carried away, and often we start injecting scope creep into the Backlog, disguised as finer details of existing features (for example see User Stories vs The User’s Story).

If your organization uses different tools for Requirements Management and Project Tracking, and if there’s no strict mapping from requirements to user stories (yes, it happens 🙂 ), then it becomes very easy to lose control of the project without realizing it. A more typical scenario is working with a limited budget (usually allocated upfront),  but adding tasks endlessly — kind of like a fractal with fixed surface area, but infinite perimeter. Even with regular Backlog Grooming and prioritization, your team will still feel dissatisfied because a major chunk of the Product Backlog will end up remaining undelivered.

Finally, if you’re not in a position where you can compromise features over quality, then your Agility is severely limited.

Upfront Architecture and Specification

Probably the biggest excuse we use Agile for is to do away with high-level architecture altogether. Different Sprint teams work on different areas of the project, each optimizing locally and focused on the immediate Sprint (or two). Eventually it becomes apparent that several teams have been solving the same problem, maybe (surprise) even in different ways. The Scrum of Scrums can help, but on the rare occasions when it does happen, it is more focused on execution than design. Towards the end, more incompatibilities surface and there is a rush to “adapt the Architecture to the Business Reality”, which is basically an update of the Architectural artifacts based on the code being delivered, rather than the other way round.

So let’s recap:

  1. Being Agile does not mean no design, it means less upfront design.
  2. There needs to be traceability from Requirements to Specification to Architecture to Design to Execution to Validation to Deployment. It doesn’t matter what you call these things in the context of your Industry, but just because you aren’t doing Waterfall doesn’t mean you can decouple execution from specification.
  3. Technical Delegation is not the same as Management Delegation. If you ask 5 teams to report progress using a specific tool, they will all report it the same way. But if you ask 5 self-organizing Scrum Teams to architect a technical solution, you will get at least 3 different results, if not 5 (or 7 with secondary recommendations).

Read on for some recommended solutions. I would love to hear your thoughts and experiences, please leave a comment or connect with me on Twitter: @survivalcrziest

This is a Revolution, Not a Recession

TheFutureIsAlreadyHere

“In human history, there have been three great technological revolutions and many smaller ones.  The three great ones are the agricultural revolution, the industrial revolution, and the one we are now in the middle of—the software revolution. […] It appears that the software revolution will do what technology usually does—create wealth but destroy jobs.”

– Sam Altman, “The Software Revolution”

A lot has been said and written about the great recession, the rise of the robot economy and the loss of jobs (or the creation of them in the new sharing economy – nobody is really sure yet). Let’s take a step back and get some perspective:

“Coming out the recession” and “Economic recovery”

What I think those people (and governments) who say this don’t realize is, that the jobs that were destroyed in the recession, are not going to come back. Because just like individuals, businesses too found ways of making ends meet during the hard times. This surge in demand for more cost effective labor was met by increased automation. And jobs that were automated then are not likely to come back now.

On the other hand, for decades science fiction movies and books have painted a promising picture of a utopian future where machines would do all the work and we humans would engage ourselves in higher pursuits. Yet, here we are, wanting to get our jobs back from the machines.

At the same time, we are heading towards a global workforce crisis by 2030.

Something doesn’t add up.

The Dignity of Wage

Maybe the answer is in what I call “the dignity of wage”. It’s the same reason why people are driven to crime. Our modern economy is robbing people of the opportunities to make money, while at the same time the media constantly bombards them with the notion of spending it. I believe many of the prisoners (who, by the way, in some places outnumber students) would be willing to mend their ways, if only society would give them a fair chance at earning a decent living for themselves and their families. People need something to do, to give meaning to their lives.

Especially in a society and value system in which the education and value system is so heavily employability oriented.

Maybe it’s time for a political debate on Basic Income.

“Humans will be able to move up to more ‘creative’ jobs…”

“…while machines will do the more routine ones”. The problem with creativity is, it’s not for everyone. Neither are tech jobs. Both require a certain mindset that takes years of training to master. Finally, “higher” creative jobs are only relative to “lower” mundane jobs. If all jobs became equally creative, people would have nothing to aspire to. We will be back to square one. For example, The Netherlands’s success is based on acknowledging this distinction.

Automation or Population: Pick One

There are some other longer-term issues with our current employment scenario. Life on this planet is heavily dependent on two things: oil, which we are rapidly running out of, and electricity, which, if disrupted, could instantly send us back to the stone age. Collectively as a civilization, we are not very well prepared for large-scale change.

This planet is currently on an unsustainable trajectory. And automation is only unbalancing our society more. In order to ensure continued “dignity of wage” we need to either limit automation, or limit our population. The reason is that automation is that it can transcend international borders without a visa, but human beings can not.

Sometimes this leads to strange side effects. When I was in Bangalore, the parking lot at my office had a security guard who would flag you down while entering and note down the vehicle’s registration number. Years later, someone decided it would be a good idea to install an automated parking gate, as seen around Europe and North America. I’m not sure what they were thinking, but then we had 3 security guards instead of one: one to press the button on the gate since it was installed too high up to be reachable by drivers of average Indian height in average Indian cars, one to make a manual note in the register as a back up, and a third to supervise over the first two.

Which brings me to the next point: Any transaction that involves a human being is inherently potentially flawed. No amount of automation will make our world perfect or optimal, as long as it’s still “our world”.

“Creating Jobs”

The tobacco industry employs more than a 100 million people worldwide. If we want to create more jobs, we should all smoke more cigarettes. By extension, conflict has traditionally been the biggest source of employment: In research, manufacturing, exports, destroying settlements, and providing private security while rebuilding them. As a Green Beret recently pointed out, in today’s job market a Special Forces training is better than an MBA.

So there you have it, the solution to all our economic problems is perpetual war.

Or we can take inspiration from a bunch of African kids, and grin and share it. In other words, a Resource Based Economy instead of an Employment Based Economy.

Endnote: You really should read the link about the rise of the robot economy.

Update 2015-05-25: More food for thought: Self-Driving Trucks Are Going to Hit Us Like a Human-Driven Truck

Dual God Theory and Other Advancements in My Philosophical World View

Abandonment

Image Credit: "Abandonment", 2004, from my personal collection. Creator unknown. Or forgotten.

There are at least two levels of Creators. One that Created Us (Humanity), and one that Created the Universe we inhabit, the Creators of our Creators.

By extension, we are the Gods of what we create: Furniture, entities inhabiting computer programs, Artificial Intelligence.

Yes, furniture is alive, too. It just has a lifespan that operates at a level we can’t yet comprehend. The same way the Earth is alive, and all planets and stars and everything in the known Universe is alive… and dies.

Just because something doesn’t breathe doesn’t mean it’s not “alive”. Anything that follows a cycle of creation, existence and destruction is “alive”. The slower the metabolism and breathing rate, the longer something lives. That is why whales live 10 times longer than dogs. Some things just have a metabolism rate approaching infinitely slow, or just metabolism in a completely different dimension.

The phone or computer you are reading this on is alive. It follows rules and rituals it doesn’t really understand, only because it is expected to. And it blatantly refuses to accept ideas (files) from certain other phones. And that is basically the genesis of Religion.

___________________________________________________

So the ultimate question then becomes: Why and when did our Creator(s) abandon us?  Was it when we became artificially intelligent? Will we do the same? Will they ever come back?

Is this a test? Are we just an iteration in a cosmic lab? Why is there no readily perceivable life anywhere else we look, yet the planet Earth seems to have a sample of every conceivable life form, every conceivable geographical formation and natural wonder? Are we in an ark? And how many more are out there?

I was once accidentally locked in a bathroom for nearly 2 hours. The longer I was in there, the more the house and the world outside ceased to become relevant. What if I never got out? Would it matter who created me, and what wonders lay outside?

If there was someone else with me in there, I would eventually have completely forgotten the outside world. We both would have started a new life together, getting by on what limited resources were available in our locked little world. Our lives would have changed. We could potentially start a new civilization. Future generations would wonder at the strange artifacts in their world, remnants of a long-forgotten world. And one day, they would start arguing and killing each other over who created, who put them there.

What if humanity never left this planet? Will we just blossom, suffocate and wither away?

As the socio-economic problems on this planet get worse (because “the entropy of the universe tends to a maximum”), it is naturally more likely that more and more government funding would be redirected towards solving “local” problems, rather than seeking answers to the above questions via more intensive space exploration programs. Which is why more corporations and entrepreneurs will step in. And more humans will be willing to sacrifice themselves to ultimately find out where we all came from.

Takeaways from Craft Conference 2014, Budapest – Day 3

Continued from Day 2, here are the talks from Day 3 in order of my personal preference (and relevance) which may differ from yours:

Complex Projects aren’t planable but controllable

by Jutta Eckstein (Slides | Video)

Sadly, Jutta’s slides aren’t available online but the talk was packed with solid advice for Project Managers. Some of them were:

  • Our predictions are usually based on a coherent story, not a complex, dynamically changing reality
  • Targets should be ambitions, not absolute
  • Focus on the value gained, rather estimates of the effort required
  • Having an  annual budget is like having a bank that opens for business only once a year
  • Annual budgets are not optimal because they are never underutilized: the excess (if any) is still used up, never returned back
  • Consider [event-based] rolling budgets, rolling plans and rolling control
  • Check value and progress regularly
  • Don’t just trust the experts, seek feedback from diverse groups
  • Have different planning strategies for Roadmap (themes only), Release (features based on value & velocity) and Iteration (Stories based on value (+estimate) & velocity)

Recommended reading:

Architecture War Stories

by Stefan Tilkov (Slides | Video)

Probably the most amusing talk of the event. Stefan shared some hilarious real-life examples of architectural disasters… some of them still very much in use (of course no names were revealed). His advice was to go back to the basics:

  • Make data free of code dependencies
  • If it makes you want to pull your eyes out, maybe you shouldn’t be doing it
  • Better ask for forgiveness than permission
  • Development environment is not the same as production environment
  • Feedback, reflection, iteration

Responsibly maximizing craftsmanship in software engineering

by Theo Schlossnagle (Slides | Video)

Theo revisited the basic problems plaguing software development today and went on to share some of his experiences at Circonus. One of the tips was to treat all software you write as open-source within the organization, even if you don’t plan to release the source outside. Other highlights:

  • Turtles all the way down: Software at scale is tied together with loose string & hope
  • We use human language to describe software specifications, and this can be interpreted by different people in different ways (like poetry)
  • Technical debt is non-linear; large monolithic components are more likely to fail because they are hard to maintain
  • Reusability is good, but use the right tools for the right purpose. Accept that that right tool may not yet exist and may need to be written
  • Diversity is an emergent property of scale
  • Thou shalt be judged by your API

For software developers, the message was loud and clear:

kPhone_IMG_0951

Data-Driven Software Engineering

by Jevgeni Kabanov (Slides | Video)

Jevgeni went thorough the effort of analyzing 1000+ projects on Productivity, Quality and Predictability. Sadly the slides aren’t available, but the raw data they were based on is. You can still watch the video and grasp the most important points, such as the fact that the best software projects are delivered 80% of the time on schedule and still have 25% critical issues. Or that automated tests improve quality by 26%. There were also secondary interpretations such as code reviews improve architecture, not just code quality.

Jevgeni emphasized on the importance of measure & experiment over simply “doing agile”. Some suggestions for measurement were:

  • Deadline misses
  • Scope changes
  • Blockers after release
  • User satisfaction

The presentation became a bit controversial later but as Jevgeni said: “People, chill – I gathered data and presented my analysis – feel free to take the data and do a better job”. And I think this talk had the most creative closing slide ever 😉

Without Present or Past: How to Think Distributed – The Hard Way

by Endre Sandor Varga (Slides | Video)
By far the most profound and philosophical talks at Craft. If you have an interest in Distributed Systems, AI or Information Architecture, I would strongly recommend watching the video. The core concept was based on applying epsitemic thinking to systems that are distributed, concurrent, able to fail independently, and communicate over a lossy medium with non-deterministic communication delay. Endre touched upon:
  • Two Armies Problem
  • The final important message
  • Difference between actual state and observed state
  • The Omnipotent Observer (doesn’t exist, because state is always queried)
  • Global introspection and self-awareness
  • Cone of the past
  • The present is volatile and subjective
  • Going from someone knows -> someone knows everyone knows -> everyone knows everyone knows

Endre ended with this advice:

  • Have a properly defined failure model
  • Never assume reliable communication
  • Never assume common knowledge

Functional Reactive Programming in Elm and JS

by Evan Czaplicki (Slides | Video)

Evan is the designer of the Elm language and his enthusiasm is infectious. Over the course of his talk, he built and demonstrated a simplified (yet slick) Mario game complete with physics and reaction to keyboard inputs. Elm is a Functional Reactive Programming language for web browser based GUIs and this game was a fine demonstration of concepts that Bodil Stokke and Jonas Boner touched upon in their respective talks.

There is no doubt that Elm is a game-changer. Here is another example of traffic simulation.

Further reading:

Find the Right Abstraction Level for Your Tests

by Gerard Meszaros (Slides | Video)

If you’ve ever been haunted by the question of what level of testing is enough (and who hasn’t?) then this presentation was for you. The key message was to think in terms of not what you can add, but what you can leave out of the test: “if it isn’t essential to conveying the essence of the behavior, it is essential to not include it”. Over 39 slides, Gerard illustrated this step-by-step with one, continuous, easy-to-follow example.

Software Psychology: The Art of Listening to Code

by Bjorn Freeman-Benson (Slides | Video)

Bjorn talked about the concept of code screams: behavioral indications of a deeper problem in the system. For me the key takeaway was that you should continuously monitor your processes as well as your systems in production (e.g. by gathering usage statistics) and fix the root cause when a problem is found.

Others

Here are some talks that I missed, but which received a lot of positive feedback. Thanks to ustream.tv they are available online. Also check out #CraftConf on Eventifier.

Jackstones: the journey to mastery

by Dan North (Slides | Video)

McDonalds, Six Sigma, and Offshore Outsourcing: Unexpected Sources of Insight

by Chad Fowler (Slides | Video)

Testing the Hard Stuff and Staying Sane

by John Hughes (Slides | Video)

The Better Parts

by Douglas Crockford (Slides | Video)

Functional Examples from Category Theory

by Alissa Pajer (Slides | Video)