Edge of Chaos

Last week at the mini-conference, one of our guys had no time to do a nice visual wrap-up for his presentation and sufficed with showing portraits of authors while just reading the extracts from their works. The topic was lean basics, and he was talking about Deming and Taylor. While everyone seemed to get bored with listening, as there was no nice visual stuff like we’re all used to now, I suddenly caught myself visualizing the talk of the boss and this worker. The story was about the boss who was convincing  the worker to bring 47 tons of iron instead of 12 or something like that.

This got me to thinking that sometimes visualization is doing lip service to us. We’re sitting comfortably, watching TV or watching presentations with nice stylishly UX’ed data, and we are losing the ability to make visualisations with our own brain! The picture is brought to us, so we make no use of the imagination “muscles” and our imagination weakens.

I’m not saying that everyone who watches animated drawings from RSA Animate is doomed. But there always should be a balance between perceiving someone else’s visualizations and creating your own. The power of creative imagination is above everything. No speaker or agile champion, or TV presenter will draw a vision of your business, your product or some function of the software you’re crafting. There’s always a time to look at someone’s visualizations, and time to create your own. Each and every “how-to” about creativity includes this magic word called “vision”. Have you ever thought why any business starts with a vision? It’s exactly for this reason.

There’s a paradox:  on the one hand, visual media is everywhere. Lots of visual channels deliver the dish to any, even the laziest perception. The problems is that the legion of those watching produces too few creators.

We’ve got 1 more day left in the year 2010. It’s time for New Year miracles. So let’s devote this day to our creativity, to cleaning the debris of anything we don’t want or need any more, and let’s visualize a

Our company is quite small (25 people). Most companies of this size focus on rapid growth and don’t pay much attention to learning. We are different. Fortunately, learning is very important in our company. We boost it in all possible ways:

• We highly encourage people to try and learn new things.
• Every employee can dedicate up to 12% of their time to unstructured learning (5 hrs per week).
• We organize internal trainings twice per months.
• We organize so-called Friday Shows every other Friday where we watch and discuss some interesting videos about UX, development, business, etc.

About a month ago we decided to structure our trainings in a better way. The resulting idea was internal mini-conference. Mini-conference is a full-day event dedicated to sessions and discussions. All sessions are prepared internally. The idea is to have a very focused learning event instead of several trainings over 2 months.

Our first conference will take place this Friday. Here is the program

10:00 Registration, “wake-up” coffee
10:15 Data Visualization Alex Tsayun /45 min
11:00 coffee break /15 min.
11:15 Node.js intro Vadim Gaidukevich /30 min
11:45 MongoDB (NoSQL) intro Oleg Seriaga /30min
12:15 coffee break
12:30 Exploring Good Experience Seth Godin (guest video) /20min
13:00 History of Kanban Anton Marchenko /30 min
13:30 lunch
14:30 Performance Metrics Alex Fomin /1h
15:30 coffee break
16:00 Marketing and Sales @ TargetProcess Andrey Mihailenko /1h
17:00 free discussions.

I am really curious about the outcome. Wil people like it? Will we keep this practice? Not sure. But we are trying new things :)

You are having your first project. In the beginning, you know almost nothing about programming languages, business domain, development process, efficient practices and other good things. In the beginning, you know almost nothing about political games, external factors, progress reporting, human stupidity, fear of mistake, boredom and other bad things. You can’t do your job effectively. Suddenly, in 10 years, you are becoming a great software developer. Or you are buried by mediocrity and never ride the wave. Why? What should you do to advance or just survive?

I think one of the most important factors is perpetual, passionate learning. Learning is the most important thing that drives software development forward. Learning is the most important thing that drives you, as an individual, forward. It drives your team, as a group of people, forward.

source: Ashiro’s LabZone

I believe, learning is a key attribute of a good software development process. Process that empowers learning will work, process that impedes learning will fail.

Basically there are three levels of learning. First, you learn as a person. Then you learn as a group of people. Finally, you learn as a whole organization. This post focuses on personal learning.

I have my own vision about software development. Most likely it comes from my personal background and products I’ve worked on (all of them web-based).

Software developers solve problems. To solve a problem in a cool way, you need to be a multi-skilled professional with quite solid knowledge from as many related disciplines as possible. Only this will give you a complete vision of the best possible solution.

Deep Specialization vs. Broad Knowledge

We are stepping on a slippery ground of deep specialization vs. broad knowledge. My belief is that at the current stage broad knowledge is better. Why? I can provide some analogies that prove nothing, but still are interesting.

Mass-production

Software development is a young discipline. It has its own properties that are not fully understood by most people. You can’t apply mass-production to software development so far, since you can’t formalize it enough. You can’t write a product specification, create design and generate complete application from UML diagrams (yes, I am aware about Model-Driven Development, but it is not even close to mass-production).

Look, there are so many related topics, from psychology to programming languages, from ToC to pair programming. There is no best way to write software so far. If you can’t apply mass-production to software development, you can’t do it efficiently with people who have a very narrow specialization. You can’t put it on a conveyer.

Science

Let’s take science and look back 300 years ago. We will see that many discoveries were made by generalists. Let’s check Wikipedia.

• Isaac Newton: physicist, mathematician, astronomer, natural philosopher, alchemist, and theologian.
• Galileo Galilei: physicist, mathematician, astronomer and philosopher
• Christiaan Huygens: mathematician, astronomer, physicist, horologist, and writer of early science fiction
• René Descartes: philosopher, mathematician, physicist, and writer

It was common 200-300 years ago. In modern science you can’t discover anything without deep specialization. There are people  with broad knowledge, but it is quite  rare these days. More often you will find people like:

• Barton Zwiebach: string theorist
• Max Tegmark: cosmologist.
• David Joseph Bohm: quantum physicist

There are rare exceptions for sure, like this one:

• Stephen Wolfram (born 1959): physicist, software developer, mathematician, author and businessman.

What is the point? Software development is obviously neither a science nor a  ‘tangible’ industry, so all such analogies don’t prove anything. But I think software development now is somewhere in 17th century compared to science and in 19th century  compared to usual industry.

With this in mind, a team of generalists with some specializations can create a better software than a team of highly specialized people. It is not obvious and we need to evaluate this assertion. I can throw some arguments:

1. Communication. Communication flows in a team of generalists. They understand each other easily and speak similar language. Communication in a highly specialized team is hard. If UI developer knows almost nothing about server side and server side developer doesn’t know Javascript, HTML and CSS at all, they will have hard time finding the best solution.
2. Architecture. Developer may know nothing about testability. As a result he creates a hard-to-test solution. High specialization can lead to local optimizations, but weak overall architecture. If no one understands how does it work as a whole — it’s a bad sign.
3. Fragility. A highly specialized team will hardly pass a “bus test”. If one of the key persons is hit by a bus, development will stop.

A Multi-skilled Software Developer

I believe in multi-skilled software developers. The right question to ask is “how much skills should I have and how deep?” It really depends, but here are the skills/domains/attributes every great web developer should have. The list is sorted by priority and I put hours that should be spent on formal education:

• Curiosity and passion
• Self-reflection / problem solving
• User Experience (1000 hrs)
• Programming (OOP/OOD, tools, practices, etc.) (8,000 hrs)
• Testing (200 hrs)
• “Sense of beauty” (Graphic design, visualization, etc.) (200 hrs)

I insist that these skills are very important for any really great web developer, but they may vary depending on software development type. I expect questions like “Why the hell you put User Experience before Programming?” The reason is that UX is an important part of problem solving. It is more important than implementation itself. UX gives developer the right perspective and makes a strong impact on software solutions. Without UX you can beautifully implement a crappy solution, and 90% of all existing software is exactly like that. IT’s crappy, unusable and bloated with unnecessary features.

Great developer should have a “sense of beauty”. It’s hard to formalize, but in general he should be able to say “this button is ugly” and “this menu is beautiful”. “Sense of beauty” is a very important property, it affects everything: visual design, documentation, architecture, source code. Everything. You can (and should) train it.

In the next post I will share my vision on Learning as a Team.

Today I’ve read two interesting posts: The Cost of Code by @unclebobmartin and Code as a Cause of Project Failure by @DocOnDev. They discuss various arguments to prove that all projects fail because of code. The main argument is that if code is free and light-fast to change, project can’t fail. OK. But this case is rather extreme and obviously impossible. We don’t live in a world with hyper-space jumps, teleportation and free medicine (unfortunately). In real life code costs a lot and it will be true in the next decades for sure, so this argumentation proves nothing. In ideal world there is no such thing as code. In ideal world you have a solution in seconds without computers, software and other complicated things. So I don’t buy this idea. Code is not the main reason for projects failure in reality.

Code is not free. Code is expensive. We do not sell source code though, we sell solutions. If it is possible to create a solution without source code, it would be fantastic. Let’s take an industry that handles tangible objects. Automobile industry does not sell carbon and metall — it sells cars. It sells a solution to transportation problem. Teleportation is an ideal solution, but we can’t teleport nothing but electrons, sadly. We buy cars to get from point A to point B. We buy a solution.

Code != Solution

I think the main problem with projects is that they provide either bad solution or no solution at all. Nobody buys stagecoaches these days, since there are more efficient solutions. If a project does not solve anything, it will fail. If a project solves something, but  in a nasty, unusable way, it will fail. You can create an absolutely beautiful architecture with the cleanest code in the world. You may have 100% test coverage, complete separation of concerns, flat hierarchies and methods without boolean arguments. You may have all that beauty, but still fail miserably if the program does not solve user’s problems efficiently.

You may argue that with clean code you can refactor it fast and change everything. C’mon, it will be a full re-write if it solves the wrong problem. Can you fix a stagecoach to make it a true competitor of a car?

On the other hand, if a projects solves a right problem, but with some issues, clean code is very important. You can’t adopt fast without it. You can’t change things and react to people demands.

Don’t get me wrong, I believe that clean code is an important thing, but it is not the most important asset in software development.

We are using Kanban for product development. It works great. As a Product Owner I can re-prioritize backlog anytime and put things into Planned state when I want to. It works. But. Every Product Owner is passionate about the product. He wants to improve so many things and do that RIGHT NOW. Prioritization is really hard and Planned state has a strong tendency for saturation and overflow. For example, our Planned state has limit of 20 items. In the worst case there were 50 items in it (most of them are bugs and small enhancements). Mea Culpa.

The obvious side effect is that most items are buried in Planned state for weeks.  A more important user story pops out and a small enhancement moves down. As a result, enhancements and bugs were never fixed/implemented. Planned column turned into Backlog column someday. That was a real problem. Yes, bugs were small and quite easy to fix, but more important problems constantly pushed them back.

We got tired of this and decided to try a new practice: The Ultimate Clean Up Day. The rules are quite simple:

1. From the start of the workday everybody who can do programming (including CEO :) take any bug/small story from Planned state and fix it. Repeat till the end of the day.
2. Someone suggested to draw a star on the whiteboard for each fixed bug and find out who is the best bug fixer.
3. Testers verify fixed bugs as soon as possible and cooperate with developers to ensure the fix. Repeat till the end of the day.

We were afraid that the clean up day will take longer than 1 day due to re-opened bugs and so on, but this did not happen. It was a very focused activity resulting in 23 fixed bugs in a single day. It was fun and development team decided to do this monthly. Next clean up day will be in the middle of December and I will re-fresh my .NET skills again :)