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.

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.