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.

The game plan

I come from a scrum perspective and the processes of scrum have affected my thinking when developing software, but since I am going to be working alone and scrum is all about the team I think I should change my approach a bit. So here is how I attempt to avoid the major pitfalls of developing alone.

1) Structure.

Developing alone is not unlike working for a boss but in this instance the boss is you. Because we know how to lie to ourselves and manipulate our own self image it is necessary to attempt to control ourselves through structure.

Step one for me is to make a room the one and ONLY place where I will do considerable work. Set up the room with only work related objects keeping TVs and other distractions out. Yes, you can think of a problem when watching day time TV but you will not go anywhere before you get distracted.

The second step is accountability. Keep a log of all the time you are inside the work room. Decide the size of your work day and stick to it, overtime is acceptable but less than say 6-8 hours is not going to get you anywhere.

The third step is schedule make it, write it, keep it! Morning is the worst for me but the afternoon is when my girlfriend is home and I don't trust my night time decisions so morning it is.

2) Documentation.

This one is important, you have an idea for the next killer app, you close your eyes and can literally see it working, you can almost touch it. But can you describe it? Do that, start writing, follow established work flow and begin from the user description, move to high level design, down to lower level and implementation. Remember if you are alone there are definitely details you cannot think about all at once and most importantly you have no tester so while you are at it start writing test cases. Be thorough because this is the only time you are not be infected by your confirmation bias yet.

Do not begin writing code right away. You will re-write code either way but you do not want to spend a month on something to discover a bug that will force you to re-write everything. Think and most importantly write! Not everything can be set in stone but writing something creates a tangible goal to strive towards. It will keep you focused and it will enable you to deliver sooner rather than later or never.

3) Methodology.

This is still structure but it is related to the software side of things. The usual scrum rituals like daily stand up, planning poker and task board are out. Scrum in general is out and in comes Kanban.

Once your design document is ready create your backlog, estimate the work and get it all up in the board. Limit the work in progress according to what you can handle and keep your eye on the ball. It would be nice to work on the graphics now that the code kinda works but first clean it up, test it and make sure it is "Done, Done, Done." You will be swamped in no time unless you keep it lean.

Create a release schedule and stick to it, make yourself accountable tell your friends, wife, mom whoever that on this specific date you will show them the final version. Get it out there right after the demo don't keep on adding unnecessary tasks, features, optimizations. Trust in yourself and know that your first attempt will be awful but the experience you will gain is invaluable.

That is what I have so far as I start doing more work I will have more detailed information.

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.