Planning vs doing

My dad possesses a great amount of patience, he reads books cover to cover, he would start to learn the electric guitar by studying musical theory, he learned DOS before BASIC and then MS Access. It took me many years to begin to understand that patience is not the only way. I have been long tormented by the battle between my dad's inherited logic of doing things with patience versus my natural tendency to jump from page to page, learn differential equations without previously memorizing the multiplication tables and writing a program without knowing where each bit of data is stored. I still carry this "first things first" philosophy with me, I will not skip boring episodes of my favorite shows, will not do something I have not planned first and I feel bad for not knowing my multiplication tables or my alphabet (sorry dad).

These are the thoughts racing in my head this morning because recently I have started skipping math intensive chapters in the GEB in order to actually read the rest. In light of this epiphany about myself I have been looking at the way I work and I identified both areas where my dad's first things first philosophy still rules my thought processes but also finding where my ADHD philosophy takes over. An example would be that thanks to code completion I have been programming in Java for two years without knowing much about the standard Java libraries, but on the other hand I am reluctant to pick up Scala because I haven't read the book yet. The battle between the planner and doer in me is raging wildly and it is damaging me at least as much as it is helping me.

In software I see these two battling philosophies at play each day. It's the good old fashioned hacker vs architect battle. The architect collects all the requirements, writes hundreds of documents, gets everyone on board, designs, meets, designs, makes some drawings, meets, meets, meets and then starts developing. The hacker spins up the IDE, jumps in, writes some code, goes snowboarding, gets yelled at by the boss Monday morning, mainlines caffeine, writes more code and repeats until the most godawful piece of spaghetti code is produced, it then gets fired, attaches ninja/hacker/guru before their title in their resume finds a partner and founds a start-up.

It is funny because both types of programmers know how to do things right. The planner does realize that spending 50% of the time on documentation is insane and the doer always has this grand plan to take the crappy system and transform it into the unified theory of everything. Yet our minds are too ill equipped for feats of such awesomesauce we simply cannot do it alone. So we are tied up into teams where the planners take all the managerial positions (the alternative would lead to anarchy, rebellion and feces on the walls) the hackers are minced through a well designed machine of bureaucracy where they secretly rebel going off at their own time to work in their own project getting ready for that start-up.

Then there is agile, and then there was laughter. Let me explain, if you put a dictator (no offense) a tripped out hippie (yes offense) and a couple of mediocre guys who don't care much (maybe offense) in a room and ask them to make a space rocket the methodology will NOT affect the outcome. If we are what we eat, then we are also what we produce (this is a disgusting statement) or closer to the truth we produce things according to our image. So it is all up to the developers and the team they compose, the right rookie in the right team can become a solid developer whereas the "graduated from MIT at 16" can also be ground to a mindless pulp by the time he/she reaches 20.

I have seen great code, I know it exists and I no doubt believe there exists the perfect team. But finding such a team, studying how it works and then trying to implement the idea to other teams is in itself a bureaucratic meat grinder at the organizational level. People, like atoms, like butterflies are who they are, we need to love ourselves and those around us, we need to accept our weaknesses and enjoy our strengths. The same bureaucratic operation that oppresses my mind into guilt and agony when I skip a page of a book is the same one that tries to sell you "advice" on being agile, productive, sustainable, insert buzzword here.

Teams are like clouds. All you can do is set the conditions and hope for the best. You can't program people to act like robots, no matter how hard you may want to (and I do!)

Till next time,

Stratos out.

Vertically integrated design in a 2.0 world

This is mostly inspired by the troubles faced by RIM and other companies.

Vertical integration in design used to be a good idea. The same company is in control of the architecture, the hardware, the software, the brand, the marketing, everything. Electronics produced this way rely on standardized interfaces to communicate with the outside world, everything is well contained and you as a company you control your products and subsequently your brand tightly.

It was such a good idea in the 70s and 80s but from the 90s onward the world started to accelerate. Design by comity and over-protectiveness slowed down innovation and created bottlenecks. To fight these, companies discovered outsourcing to speed up the mundane parts of design which at least allowed for features to have a quicker time to market. But the outsourcing solution is not enough in the 21st century world, time to market of 1-2 years is unacceptable in most industries if not all of them.

Mega projects are feeling the strain of trying to catch up with newer, leaner, more distributed designs and these growing pains seem to me to be the driving force behind agile methodology adoption by large corporations. If you have read some of the agile books out there the introductions sound like pitches aimed at alleviating the major problems faced by industrial mega projects. Elimination of bottlenecks via feature teams, knowledge transfer via team interactions, better control via transparency, etc, etc.

But agile has had mixed results. Change itself causes some initial slowdown in production or the fear of a slowdown. Management and employees don't easily embrace changes that undermine their job security which is a natural byproduct of some agile methods. Not to mention that often the wrong methodology is applied to the wrong project due to a silver bullet mentality.

And then came crowd-sourcing and the shit really hit the fan! The most affected industry of all is the mobile phone industry. The smartphone wars that have ensued are a testament of the changes going on in the world of electronics and software. Six companies are in the ring, one so far behind it is irrelevant, yes that's you HP, sorry. One already accepted defeat and hopes to band with competitors to survive, nice call Nokia. Microsoft, after having their crappy windows used to wipe the floor with, comes back with WP7 but is it too late? RIM is faced with mounting pressure to do something, market Blackberries to toddlers maybe? And the two kings of the ring right now, Apple and Google. Well Apple was the king to be precise before Google and their Android army started kicking their butt. But Apple, RIM, M$ and co have banded together in a last ditch effort to stop the green menace.

In the battle of Android vs everybody else it seems that Android cannot survive the constant barrage of patent trolling, leveraging the existing power in markets outside the mobile arena (WP7 and Xbox, iOS and AirPlay, MacBooks, iPad, iLife) and challenges posed by a newer and not as mature platform. In all this mess my money are still with Android. Why is that? It is not my natural tendency to side with David against Goliath, I mean Google is close to taking over the whole universe it isn't a David. It isn't even their motto "Don't be evil" that makes me like them so much.

Google will win because vertically integrated design in the 2.0 world is doomed to sink like a monolith. iPhone5s best features are already integrated into Android (smells like counter lawsuits by Google?) or are about to be topped by C2DM functionality. Simply put the practices of industrial secrecy, design by comity, content approval processes are no longer relevant in today's fast moving world. Time to market of over a month is too much at this age. Your only hope is to make your source open, attract as many individual designers as possible, give your platform to anyone who asks for it and let them change it as they please, in one word: Android.

Till next time,
Stratos out.

Going cowboy

Software development is a unique endeavor there has to be a balance between "out of the box," creative thinking and realistic, grounded design the problem is how to keep the balance across all team and company sizes. A small team will focus more on getting results which can cause issues of proper documentation and even bad design; also on the creative side of things the smaller the team the fewer the chances to see things in alternative ways which means testing may suffer and solutions may be inefficient. On the other hand anyone who has experienced development in a large scale organization will testify that to control the chaos of writing code bureaucracy in the form of documentation, meetings, processes can become overwhelming and crush good ideas, spirits, productivity and in the end lead to more chaos.

Agile practices have been hailed as the messiah that will save us all from both the oppression of bureaucracy and the trap of coding madness. But the messiah asks for full obedience if not to all practices at least to the philosophy and as every messiah it is met with fierce resistance from the status quo. Going agile means more than getting a few post-it notes and a filling the timetables with rituals it means that the entire organization needs to relinquish control. The customer loses the well defined contract, the managers lose direct control over their employees, the designers are no longer in control of their own work and the one thing that gains all control is "The Team."

But I am no longer a member of a team, I have no manager, no scum master, no product owner, I don't know my customer by name. I am in the world of cowboy coding and I have very little in terms of methodology and practices. In the following weeks and months I will attempt, besides learning how to write good apps for the android platform, to lay out a method or perhaps a collection of practices that will keep me motivated, focused and productive while working alone. I will post updates, tips and lessons learned and hopefully in the end I will have a solid collection of practices to assist those who also walk this lonesome path. Queue the music I'm a cowboy, on a steel horse I ride...

Till next time Stratos out.