Yes we Kanban!

Moving is over, easter vacations are over so now saturated with good food and beer I have finally setup the basement to my little work room. It is all very temporary and I have plenty of things that I could get but at least I have some strong lights, three whiteboards, a laptop and a sofa. There is a problem with the morning schedule though, interruptions are too frequent. Either over Skype, Gmail, phone or in person people talk to me and I talk to them and which makes working hard. I am contemplating going vampire (sleep during the day, work at night) but that could mean that my friends and family in Greece will not talk to me too often.

Lovely letters!

In other news the Personal Kanban board is up and populated and I am in the middle of writing a design document for my first professional application. In the meantime catching up with intents and activities (android thingies) may take longer than I thought but I have a whole weekend to read up on that.

Ok break over back to work.

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.

Hello World

Hello everybody, my name is Stratos Xakoustos. Up till very recently I was working as a software engineer in a large Telecommunications company subcontracting for an even larger Telecommunications company. For the last half year I have been dusting off my programming skills after work and lately I have delved into Android software development.

This blog will follow my journey into the world of applications design, development, debugging and deployment. My goal is by the end of the summer to have a speed of roughly two apps per month and maybe make some pocket money because being unemployed isn't cheap... By the way if anyone knows of any job opportunities feel free to drop me a line.

Wish me luck!

Till next time Stratos out.