The Dark side of being a Software Developer

IBM launched a campaign almost five years ago : „Where teams are heroes“. On conferences they distributed light blue t-shirts on whose back a team of software developers was pictured as super-hero cartoon heroes. We all want to be such heroes don ‘t we? Be famous like Kent Beck, Martin Fowler or Uncle Bob Martin , Anders Hejlsberg, Scott Hanselman and others, don’t we?

And we all kinda live and work in that dream. The long hours and efforts spent on last ditch deadlines, the lengthy and emotional discussions about a problem and our effort to be just the man who saves the team and the project. We all like to be the person people go to fix hard problems.

I lived the dream also. I worked day and night, fifteen hours a day weekends and holidays on tough projects which needed to be finished by a certain deadline or the client and our company will be in grave peril threatening their very existence. Does it sound familiar? I even worked several times from dusk till down, twenty four or even thirty hours consecutive too meet a deadline and afterwards I felt like a god. I’ve leaded a team to hell and beck and completed those damned screens just in time for the client presentation in the morning. And I’ve been doing such shenanigans for some time now.

What is the cost of such a way of life? What is the price we as people pay for doing such a service for our company and our clients?

What is the dark side of being a software developer?

SAS Special Forces WWII (Africa)

Let me tell you my story. Something that happened to me at the turn of the millennium.
  Let me tell you what price I paid for my way of life.

My wife threatened to divorce me a dozen of times, threw me out of my bedroom (temporarily thank God) , yelled at me continuously and generally made my life a living hell. Often I was made to choose between my family or my work. And both seemed critical at that moment. And I really wanted her to understand that what I was doing was important and critical and serious consequences will happened for multiple people if I don’t deliver. And she would yell at me and tell me that I’m not a soldier, or a doctor or a policeman that I do not work 24h a day and I’m not on back and call every day of my life. The situation was more drastic when my son or her were sick and I had to work.

Ultimately I tried to work from 5 a.m to 17 p.m , but the stress and the long hours and the lack of sleep just put me into bed for a couple of weeks. What a bummer.

Not my health, not my wife were the most horrible, most darkest and vilest price I had to pay. It was my four year old son.

One day he just wouldn’t budge from me after lunch. He cried and clinged to my leg and didn’t want me to leave. And I didn’t, but started to play with him. During the play he said to me that he had a dream : “Daddy, I dreamed that next time you will go to your work I will not see you for a long, long time”.

My work gave my son nightmares that he is going to lose me.

When my mother put him to bed one night he asked to her if I’m going to come to bed next him when I stop working for the night and why is daddy working during the night after working the morning and the day and the last five days like that.

My soul froze and my eyes started crying and my scream stopped in my mouth and I cursed my self for being such a monster to my family.

Is it really all that important?

The client set a deadline but made thirty percent change on its original request all which was accepted by us and the deadline slipped day by day into oblivion and often we would rewrite the same feature or screen several times. The work would just pile on with an even increasing defect rate due to long hours and stress and the dead line would remain the same and my colleagues and friend and I would soldier on trying to fix that which was already broken.

During that time I told my self that in the end it will all be worth, everything will pay out and my family will live better and all the people around me told me that I’m being stupid and an idiot.

But I stopped for a minute and made a mental calculation. It just didn’t pay out. The amount of personal loss compared to the business gain I expected and received where just not comparable.

Yeah sure the business is important. It puts food on our table and we must live by our word to deliver something to certain day. I believe it still and live it still. But you know, being a software engineer is just part of my life the other is my family. I still work in the evenings, but not all evenings . I work because I like it, and enjoy it and I get to learn something , not because someone made me. But my place and my obligations are to my family also and that is an area I really, really messed out. 

The emotional health of a software system

 

The eternal truth to software development is its inability to produce any meaningful systems without a coordinated effort from a diverse team of individuals, lots of disparate activities ranging from design to development and quality assurance and finally with the same effort applied to the maintenance and operations of a running system. From the deployment of patches and extensions, to the cleanup and data hygiene of databases to the scaling of the system and hardware and software maintenance efforts.

As much time and effort is spent in the art of software development, often not much effort is spent during the operations phase of a software project.

A rule I’ve often observed in many many projects I’ve been part off is the linear degradation in the effort of maintaining all the scaffolding and activities which are not directly related to coding of a software project. Thus enabled entropy degrades the product and seeps into its operations lifecycle resulting in emotional and business drawbacks for both the organization and the stakeholders included in the project.

Should we accept this? Should we accept a system of development with diminishing software engineering efforts , should we accept the fallibility of people to care and work at top quartile engineering capacity?

I’ve seen that any significant software system, shop and development environment needs guardians in the form of an engineering educated project manager and a strong cadre of technical leaders which have the authority and will to enact and drive and force a strong commitment to all software engineering scaffolding practices which combat the intrinsic entropy found in all human endeavors, especially software development with its heavy intellectual burden, high abstract concepts and emotional stresses.

A common image of software developers is of introverted emotionally challenged people. Truth be told I’ve worked with quite a few of them in my time. Thus a surprising aspect of our live is the emotional toll software development takes from each of us which is directly linked to the quality of work we do and the state of the system.

Human emotions, feelings and states directly transfer to the work we do. The pain of working with  highly abstract concepts, what in truth software development is, is the primary source of all the bad decisions, all the accumulated technical depts., all unsolved problems and defects a system has.

In order to ensure a proper functioning of a system and a team special need needs to be put in and placed under constant guardianship in order to focus on emotional and mental health of the team working under such adverse, but normal conditions.

On the life

 

As software engineers our life are subject to forces which are not entirely in our control. The chief are health, family and politics. I will start from the latter and go the former, discussing how a software engineer can mitigate some of their ill effects on her life and career.

Politics is the art of the achievable, of getting things done. I’ve listened to an audio book version of the ‘Prince"’ by my namesake Nicollo Machiavelli. While some may disagree with its context or rebuff it in its entirety on moral grounds alone, I generally find its context true and suitable to any endeavor where you have a hierarchy of people working in environment with limited resources, or any environment where you can find humans. The truth is that in the base of the human nature lies the instinct of self preservation, which is often achieved and perceived to originate from ones advancement above her station in respect to the domination and control her peers. When working in any organization there will always be personal goals, issues, treats originating from people working around you, above you and bellow you.

‘I just want to do my work, and be done”, some may say. And you are obviously right in that life philosophy, but given the fact that out there are people who will benefit by inflicting or just by you incurring a loss of some kind. Thus a wise person should strive to position him self in a prepared state, watchful about what is going on around him, about the goals and positions of the people in his circle. He should align him self with the people who have ambitions in alignment with his own, make useful and not a threat to people above his station and respected and not an obvious impediment to people bellow his station. A wise person would also be aware that each state is only temporary and thus not permanent and that person will always need to be on the lookout for the next situation and have always a backup plan when all things start to fall apart.

In short going to work nine to five and forgetting about work afterward is not a really good strategy any more.

The second ill which may befall a software engineer is family. I’m a family man, my family is my sanctuary, my church and holy ground. I short my family is my life. But often the work we do puts us across the needs and wants of our family members. Our spouses, our fathers and mothers, out girlfriends. This is the truth.

If you read any book about people, or software processes or any topic related the the culture of software engineering you are going to pass by references to “Death march “ projects, long hours and weekends spent working, broken projects and divorces which resulted from those activities. The pressures and the time, of the time, we spend working maniacally in order to reach our deadlines reflect negatively on the needs and goals of those around us. No amount of money or bonuses is going to mitigate that. Maybe you live on a farm and regardless of your work you must spend time working on the family estate (new a guy who had a problem like that) or your wife is fed up being all alone with the children while you do whatever you do. And then meeting your business commitments and your family commitments is going to get really though, and your morale and your performance is going to drop and your private life is going, well down under.

What can a savvy engineer do than? First, you can’t please everybody. You have a limited resource, your time, and two opposing forces. What I’ve found out is that you need to be open at the beginning to both parties about what you can do and what you can’t do. And then be prepared to take blows. Or marry a wife who will not mind you being around so much. Or find a nine to five job.

The third and most important is your health. Your mental and physical health is the most important assent you are having in your career as a software developer. In order to achieve the level of performance and excellence you are able and required to produce you must be mentally and physically fit. Thus you must always leave room for physical exercise and strive to conserve a positive outlook to every situation and prospect. I can’t remember how many time those two thins helped me, and I can remember oh so well how many time one or the other failed me.

Experience is never taught, only learned by doing. Thus read and watch what others have done and experienced. A good documentary I watched five years go showed a year of frenzied development of a team of engineers at Netscape developing the first version the Firefox open source browser. That is a good example of what kind of life we lead.

But all is not dark, and all is not done, for we are human and we make mistake but to be human is to be able to learn and change, to adapt and improve thus we will make our lives better trough knowledge, spiritual advancement and physical toil.

In the beginning there was the command line

 

In the begging there was the command line, and it was good. Then came the user interface, the mouse and expediency of ease of use. The word was “Don’t let me think” and thus the web was begotten.

And the cometh forth a beast of many heads, or many releases which swarmed into one version, and Google Chrome rose into the world and brought the command line back into the fold.

At first it was the ease of search, ease of address typing, moving and blurring the difference of an url and a query. Now, it was the turn of the information and the knowledge Google brought about your needs, your work, your life. And thus the time of search cometh to the world and the word was good and the masses were fed by the wine of information and food of quick results.

And the devil of engineering said “It shall not be enough, what was before shall come again, the circle of technology and innovation will turn again bringing what was before into the new and bright” and developers brought search to their applications and then it was not enough to have search but commands typed after the url came as orders of the divine and users could use the shell as the address bar and the web page as the console.

Thus in the end there was the command line. And is it was cometh again. Technology turns, what was old becomes anew, rediscovered, dreamed again.

I' am student of technology, servant of engineering and topologist of software. During my travels trough countless projects, books, presentations, frameworks, languages, databases spanning decades now I remember things which once were during the first books I’ve read at the end of the eighties and the nineties and the stuff I read and do now, and often I see old ideas and technologies rediscovered and re-implemented in new spaces.

I’ve read a book about the basics of computer and operating system architectures, how hardware and memory functions and how thing communicate and stood amazed how the same solutions and patterns are copied trough the architectures I’ve done and those I’ve dreamed.

I came to see this as truth about our loved profession. Everything which once was will come again, thus making the study of old systems, old patterns crucial for the future of our advancement. The critical thing which needs to be adopted as practice in our companies and universities and training grounds, and which is known to all old hands who survived several decades of shifting technologies and trend is that regardless that a technology is not used and more, or is redundant that there are core lessons and practices which will prove useful in the problem spaces of now and tomorrow. 

Croats at work

Aleksandar walked down the old roman street. Renaissance buildings loomed around him filled with shops and dolceries. The street was filled with people both native and foreign to this old city from Greek myth. 
Aleksandar was too busy to notice what was going on all around him. The street was named Sergijevci. A noble important family which stuck with the first Roman emperor and helped him defeat Cleopatra and Marc Anthony in the naval battle of Actium.
Behind him the Golden door of the Sergiai family welcomed more people in the streets ancient womb.
The unemployment office was glass building set between the social security office and a computer shop. Aleksandar paused there to look at open positions posted on its crystal walls and read those focused on software development. Behind him children laughed and played in a playground filled with centuries old roman stone sarcophagi.
A men approached him from behind. He was older, thin, neatly dressed in an official sort of way. He stood beside him and studied the same open position as him , that of a lowly developer in one of many small software companies located in Pula.
“I think I’m going to go to work outside the country”, said the man.
Bored Aleksandar said, “Why, what is wrong here?”
“It is hard to find proper work, the money is not so great for us and people out there know how to work and pay a man. I have a friend who is a foreigner and his lives here, he is married to a local girl and he says ..”
“.. that he is shocked and surprised at out mentarly, how our government works, how people work and where he comes from is completely different and better and we are yet to achieve that level of perfection.”, Alesandar finished for him.
Aleksandar was irritated by the old man, he heard the same spiel many times and something always chaffed him about that. Now he finally got it in a flash of inspiration.
“Oh, yes. That’s exactly that”, said the surprised old man. “I mean isn’t he right?”
“Of course he is right. He properly should be.”, said Aleksandar. “He comes from an another country, from another language, another history , another culture and another set of genes. But what is wrong is that we automatically assume that we are ‘wrong’ and he is ‘right’!”.
The old man looked at him quizzically and asked. “What do you mean?”.
“Why are we under developed, what is wrong with us and our system?”, asked Aleksander and then continued. “We are ten years from a war, the world is in a recession and we are struggling. But people are generally content, people try and learn to work and improve them selves. The law protects workers rights and we are covered for health insurance. Each of us speaks several languages per default . I speak three of them not including my own. I’m well versed in culture, history and sciences. And I’m a highly qualified software engineer not under qualified work monkey.”
“But surely you do not forget the problems out system has with long waits and byzantine bureaucracy?”, asked the man irked.
“No! But every country has problems with its system and everybody struggles in some way and then everybody chimes theirs is better. All, except us.”, said Aleksander. “My point is that we are not the ugly step child of Europe. We are not worse then everybody else. Out engineers are talented, work hard and work long hours and go to great lengths to satisfy the client. The clients I worked with were all satisfied with out work.”
“Well then I see I have your options set”, said the old man. “I bid you good bye then. I have trip to prepare.”
With that the old man tipped his head, turned and walked in the direction of the old austro hungarian ship yard.
“Bye.” , said Aleksandar.
He stood there a few moments. People passing around him. Some searching for work, searching for a better future and others going on their way to their place of business. There were a lot of lawyers offices and local official buildings in the area.
Aleksandar shrugged and turned around In the opposite direction the old man left towards the forum of the city to glance to the temple of August and rest his thoughts on the city Julius Cesar built.

MS Community : The lean software development talk

Is it proper for my ninetieth post to be about a talk I held today at the monthly MS Community Istra gathering on the topic of "The Lean software development process"? I don't know but well it was a wonderful evening.

There were some news around it. It was the first talk I held as an independent consultant since I left Labirint/Cenosco earlier this month.

And second it was the first talk I held by using only my browser as the presentation medium using the amazing Prezi service and YouTube. Prezi is presentation re-imagined, it allows for a more dynamic and spacial orientated presentations and is easy to use. You can see my work in the frame above this text.

There were around twelve people present which was nice. I started the talk with some ground rules and my estimate how long the talk will run. I said one hour and half, it took me one hour and twenty minutes.

The talk was broken into four sections :

1. Lean and muda
2. The cycle
3. The steps
4. The practices

In the first section "Lean and muda" (muda is an Japanese words meaning waste, but in Croatian it means "balls" so figure it out ... are balls a waste? ) I introduced the basics of lean in production by focusing on the Toyota production system and the seven wastes (transportation, inventory, waiting,motion, over -processing, over-producing and rework) and their correlation in software development. 

I also introduced the seven principles of lean in software development and the key principle of kaizen whose examples I talked about in the whole talk.

The second section was the most fun for me. I talked about the basic lean software process I used trough out my carrier what are its rules and how can it be constructed. The principal accent was made on limiting cycles and steps into cycles be value delivered not time (time is important but the first delimiter is value not time, time is used to remove the fat of the value delivered to deliver first what the client wants to see more).

There is a note in the second step which is not visible in the prezi, squares represent big chunks of work and circles represent smaller chunks of work.

The group

The third section covered each step in a typical cycle : requirements, architecture, development and deployment. This was the most fun, since I elicited input for the public. For example when I discussed architecture I did a quick collaborative high level architecture diagram about a system for tracking cargo loaded. I asked do we need a database and got answers : " A small database, Oracle, SQL server ". So we picked SQL Server, then we picked stored procedures as a way to interact with the database and then Silverlight as the UI technology. For each decision I asked a dozen questions to show the group that architecture decisions matter and define how the rest of the project will progress. 

In the final section I covered the practices of doing daily standup meetings and pair programming which I consider real important practices. 

After the prezi was done I showed a clip on you tube which was a satire on the "Fall of Hitler" movie about an agile project going wrong oh so typically. This video is not about my political, or religious beliefs and its intent is only to show how agile projects often fail not to offend any one,

The developers song

The developers song by Nikola Stjelja on GoAnimate

Video Maker - Powered by GoAnimate.

As I wait for my one hundred twenty projects long solution to load I pray the Lord for my soul to keep.

As I dream of complex code, loops, functions and classes, patterns and database I reach for Hermes the god Alchemist and inventors in my hour of need.

I no longer can reach the dream of perfect machinery

I no longer can feel the systems beat

It is one long chain of stack overflow, exceptions and performance pits

No tests to speak of, not builds to rely on

Just one long, long evening of darkness and despair of enterprise code ready to be released

It is time for me to step down, to reach my bottommost level and open my snail farm on a far away island

Is it is not that the future that awaits us all?

Hermes doesn't respond

My soul is mine to keep

The solution is loaded , all one hundred and twenty projects long

The code is green and blue and yellow and red

I start pounding my keyboard

I start building my code

It takes a moment for the grid to pop up

For the exception to raise I fix the problem

Release my code I go home happy, ready for tomorrow to do it all again.

Different styles, different problems

 

In software development as a culture there are multiple personal and organizational styles of development, process and project management.

What happens when a person , an engineer, switches from an organization which favors one style to an organization which favors another?

Usually there are two very negative responses which just popup continuously:

• Shock and negation,
• Aggressive takedown of the alien style

In my experience you can expect them from senior engineers who recently switched from one culture to the next. I’ve always waited with apprehension a new hire to see if she is going to throw a ruckus and put everything up and down or is she going to integrate into the process and contribute normally to its advancement.

I’ve seen people shockingly negating the new mindset and creating grief to everybody around them until they either accept the new state or leave. Of course I’ve seen people who continued to push their style onto others until it infiltrated certain parts of the project (have you ever heard bout this : “Hey why is this code in a different style then the rest of the application, don’t you guys have an architecture?” and the response “Yeah, that was Ivan he is a bit strong headed about some things, can’t do nothing about that.) and created a mess which just increased the maintenance cost of the project. That is not really good.

I’m a long time listener of the Manager and Career Tools podcast. One of the podcast I’ve listened to in the last few months is about your first six months in new job. The core idea was “do not make waves in the first six months”.

We are all engineers here, we want to improve things make them better. Something's in the new project, new organization are wrong or not optimal and can be corrected. But some aren’t. How can somebody figure out the difference?

So many times I’ve participated or seen arguments of a technical solution which just boiled down to individual preferences. Both solutions fitted the problem well. And then escalated into flame wars.

What I’ve learned is to pause and think: “is this a real problem, or just not my preference”.

Usually people are more receptive to solutions how to solve a problem then they are to changes to their preferred style. People do not want needless change, we all want our peace and quiet. We don’t want to pick a new style, we want them to use our style for better and worse.

A funny cartoon I've created about the problem:

Space coders - the enum battle by Nikola Stjelja on GoAnimate

Video Maker - Powered by GoAnimate.

What is technical leadership

What is a technical lead?

In my opinion a technical lead  is a person who is senior enough and has the required set of skills that can manage the technical aspect of implementing a complete software product or just a part by managing the technical aspect of its development for a small team of up to five people.

The principal focus of a technical lead is the correct technical implementation of a set of requirements by her and her team.

How do I become a technical lead?

In my experience technical leads (or whatever name they have) share the following characteristics:

• A Technical lead has a level of technical excellence in a all areas core to the product development
• A Technical lead has the ability to create a technical vision of a finished product, transform that vision in a set of tasks and lead people in their development,
• A Technical lead can take onto him self to develop the core of the product being developed.
• A Technical lead needs to have soft skills

In short you need to have all those skills and experience to make it to a technical lead level. But that is not enough. To be successful as a Technical lead you need implicit backing from the organizational management structure. A Technical lead is responsible for the technical aspect of the product being developer and without a proper and implicit organization backing he cannot achieve her goal because technical excellence and soft skills are not enough to technically lead people.

On aspect of the technical lead job is to be the arbiter of any technical decision. In short words if there is any doubt what technical solution is proper for a given problem the duty of the technical lead is to accept upon himself the responsibility of the final decision.

What does a technical lead do?

A technical lead has several areas of responsibility. He is is both an engineer and a operational level manager and thus his work covers both spectrums:

• Translations of business requirements into technical tasks
• Planning and organization of technical tasks
• Technical planning and technology selection
• Team technical communication
• Stakeholder technical communication
• Project technical quality attribute management
• Construction of the project core

OF the entire list the following two areas of responsibility are important:

• Construction of the project core
• Planning and organization of technical tasks

The technical lead must accept and develop the most important and critical part of any project. And he also must manage the implementation of all technical tasks related to the product being build.

Agile Architecture

There are two core principles to architecture in an agile environment which worked for me real good :

• Document only small slices of the system one at a time at the time you need them
• Be as specific as you need without going into too much details

A typical business system, one that is software intensive, is a really big and complex. When developing one such system it is impossible to document everything at once. What I do is to create a general corner stone architectural specification that defines the core architectural areas and principles of the system, a reference architecture around everything will be build and then create a series of small architecture documents (Architectural Notes or Memos) which are slices of architecture targeted at a specific system view or functionality which is developed for a first type. Architecture is a generalized specialization so such documents must convein all the information one needs to implement the designed architecture but not specialized too much in order prevent the multiple variants the same architectural areas can have. 

It is important not to design to early , but at just the right time. The goal is reduce the amount of time passed between the design creation and the implementation and to focus the architectural effort on the architecture which is need right at this moment of the currently developed sprint. 

Designing and documenting and architecture slice is one part of the whole problem, even when you create such a design at the right time with the right amount of detail the majority of the subsequent effort is spent communicating and reviewing the architectural implementation. If the implementation part is done by the architect and the senior team (such as the core of the system) a significant part of the architects effort is spent disemminating through the development team (or teams) the culture and the ideas required by the architecture design. 

Software is plastic, and programming is flexible. Event the most pure architecture can be twisted, scratched and mutated in something recognizable. The best way to insure an architecture to survive is to set up much of its essence in code and build tools which guide the developer down to a certain way of solving problems (which has its own problems , which is why architecture should be approached slice by slice and nothing is one hundred percent fixed in stone and unchangeable) and to integrate its core principles into the development culture of the development team which will ensure it gets adopted by every new team member.

Lots of teams make use of the shared tribal team identity as the only reference how things should be done by the project. This practice is spurned by software engineers, and with good reason, because software cannot be developed with tribal memory and shared culture alone, documentation must exists, tests and build tools must exists in order too enhance the human falabilities to which we all are susceptible : short memory, illness, death, holidays and leaving for a better opportunity. In its essence agile development values people over processes and interaction over rules, it doesn't mean no documentation or processes should be in place. We all are humans, and by definition fallible. Agile architecture should strive to reduce the human error by documenting and the essence of small specific slice of the system such as : grid architecture, background process architecture, form architecture, repository architecture, commenting system architecture etc.

Short is better for software developers, people will more eagerly read a ten page document then a one hundred page document. They will read it more often and learn more from it. It is also really easy to communicate a short document then a large one. Also, less errors are introduced in a short design then in a large one.

The agile manifesto reads as follows:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

The agile manifesto clearly indicates that things on the left are more valuable then things on the right, but things on the right have a value. They are second to the things on the left, people have more value to software development over processes and tools, working software is king over documentation. But a balance must be made, without a documentation who will understand what is being developed? Without a set of class diagrams that show the core architecture for a subsystem from top to down and text describing it who will understand the code without someone guiding him through? 

Each day when I start my work I say to my self :

Your job is to enable other people to do their job better

I'm a technician and my focus is technology and the development team that works with it. I'm a software engineer by trade and a craftsman by soul and I really think only three things are important in software development:

working software, people and communication

For me agile architecture is that which maximizes those three things.

I'm too old for this

I worry to much I'm going to wash out due to my age. I'm currently, at the glorious time of writing this post twenty nine years old and by the Lords grace I'm not a year older. And I worry I'm to old for this job. This makes me really unhappy since I have a small boy and I wonder how I'm going to provide for him since I'm no good at anything else (well I'm mediocre at a lots of things, but that is nor here nor there so we are not going event to discuss it) and this is all I have for now.
I don't know a lot of developers older then me, a few older then forty and none older then fifty. I really do not know what is my future career plan. I generally planned to gradually move to an architecture design position, since I'm naturally inclined to it and its not a development heavy thing. As I grow older, and as people grow older, we cannot learn as easily and as much as we could before. New technologies emerge and if you want to stay in this job  you need to spend extra time learning them at your own. But later I just can't mange to force my self to find the computer time for it. Sure I read books and blogs, and pay really carefully to code examples for technologies I'm intereseted. Curretnly I'm reading WPF 4 Unleashed by Adam Nathan and Patterns of Enterprise Application Architecture by Martin Folwer, plus I've read the entire MongoDB on-line documentation. But reading is not enough, you got to feel the code bellow your fingers. You just got to. And I really don't to much.
During my holidays I was to washed out to do anything and I told my self its OK you need to rest. But when I got back to work it continued. Sure I started some small coding on the side for learning purpose, I started reading books and blogs and watching presentations but thats just not enough without coding.
What is going on with me you wander. I think a description of my life after work is in order. When I'm finished working I'm with my family helping with the kid, doing house chores the whole nine yards. I put the kid to the bed and around ten o'clock in the evening I'm done with everything. I then go to eat my dinner (yeah I know its kinda late for that, but thats life) take a shower and I'm free to do as I like. I so want to do some coding but when I just think of sitting in from of my computer, my internal will power just crumbles. So I just watch a TV show or read a book. Very depressing, and very unhappy like for me. And then I start to wonder, this is my age doing this to me. Before I didn't have problems with this. Before I could do this all night old. I'm twentynine years old and I can't muster the will power to do this everynight, whats going to happen in ten or twenty years. How I'm going to learn Java or Erlang, or any other technology I'm going to need?
I just don't know and I'm really not happy about it.

Nine to five

It took me a while to make my self see and surrender to the fact that not all people I work, I've worked and will work with me in the future, have accepted The Life, or the way of a software engineer or craftsman.
Oh, how I've grown wiser and older. I just might grow a beard and be a guru of some sorts. Certainly there is a niche I can squeeze in a pretend to know what I'm talking about.
But alas, I didn't grow wiser just battered down by the entropy that is the , oh so typical , human philosophy of working from nine to five and then at five o' one forgetting that work even exists.
Well I can understand that. Work is work, and it isn't the whole life. But for the way of a software engineer or craftsman isn't just work , the daily grudge of projects, meetings, coding and testing the constant battle of will and code and the requirements that just won't fit into the application mold. It is just not.
For me it is something different, something more. A thing to be proud of , something to leave for posterity. Is the way of living where you read, learn, exercise your self and improve your self. Year after, year continuously. And the work is the place where you apply your skills, your learning, your spirit into something tangible, something you can be proud of, an achievement.
Am I , or people like me, better then the rest. I think not. We are just different. I often found that people with the nine to five mentality are predictable, they approach each problem in a similar fashion, they apply the same solutions every time, day after day, application after application. On the other hand, the same errors are repeated, the same problems occur nothing is improved until pressure is applied from the outside, or if not they succumb to the technology wave, left behind with outdated knowledge and if something doesn't come by, a new project or a new job where the can learn new skills in a nine to five way they are really frakked up.
This is what scares me the most, as a developer, to let my self loose, to relax and to in a matter of years outdated, jobless, and skill less.
We work in teams. We seldom do any work alone. Teams can be organized differently, they can work differently. But one constant remains often, in teams there are some people that want to improve them self and the the work they are doing and those who just can't see the need to bother to do so.
For this was an enormous amount of stress, battling such teammates day after day until it downed me. I can't change them. I can't force them. I just can behave with my code, my tasks the way I think is right and if they'll follow me the batter or if not I will refactor their code or leave it as is.

Short, short deadline sprint rules for success

Imagine this situation, its 24 hours before a very important deadline and your project isn't ready. But you must show some progress to the client, something anything to stop them from stopping the project and turning to someone else. What do you?

I've been caught in this situation several times already this year, and will in all probability caught again, and its not easy or simple to handle. For each project I was a technical lead, and the responsibility to actually do the task by the deadline fell to me.

The following rules helped me:

1. Cash in your relationship chips , you'll need them to motivate your people and make them buy in the effort required of them.


2. Write a task list of all tasks needed to be carried out in order to successfully meet the dead line, and then filter it out to the bare essential. It's time for brutal reality, not Christmas wish list making.


3. Take the core, the most difficult and most important stuff on your self. They made you a technical lead for a reason. Now is time to earn it.


4. Distribute the remaining stuff to each team member according to their capabilities and aptitude.


5. Make sure no one introduces new (or reopens) new defects into the system. Test the core twice before committing. Break heads if necessary. It's not the time to create more work.


6. Do not commit unfinished work. It either is done, or it isn't. Only pure 100% completed and tested changes go into the repository. Make sure everyone is on the level with this.


7. Do standups every four hours in the first twelve hour period, then switch to two hour standups for the remainder of the sprint. Track only completed, not completed progress on the created task list. Look for problems, and replace people who got tired or the tasks assigned to them are to difficult to handle. Pair programming was proven effective in both cases.


8. On achieving all (or the majority) of the planned task code freeze the repository, and label it as such. Do not allow anyone to commit now unless its a critical defect fix you personally authorized. Break heads if necessary.


9. After the code was freezed, test everything on your machine. If everything checks out label the code in the repository as such.


10. Publish the product to the production environment and then check it there once again. If everything checks alright, go home to your family for a head bashing for spending 24 hours on work while your kid won he's first soccer prize (or similar). Be proud of your self for achieving something great and meaningless.

The following rules(principles, steps) work because there is a clear scope of the work to do in a very short amount of time. Everyone is clear on the importance of the work to do and what is the price of failure.

The two most important thins are frequent standups and the written, prioritized task list. Why? Frequent standups remind everyone one the goals and the principles of the work to do. They allow faster knowledge sharing between team members and allow you to get a clear view of the progress achieved thus far, of the problems had and allow you to frequently react to those problems in order to remove the impediments thrown in front of the team.

Remember in the end everything falls to you. You must be the leader, the one that starts first and goes home the last. The one that pushes the code to the production and says is done. At four am there is no one else. Its your responsibility to sleep for two hours and show to work to check if everything is OK with the business people showing the product to the client.

You are the hart and soul of the team. You must show firmness and clarity of vision and command, you must be supportive because without them you are nothing . You are your team, and they are yours for good and for worse.

Another day sprint

I'm concluding another day and a half development sprint. I started yesterday at five a.m. with a trip to Zagreb which lasted till six p.m. , filled with back to back blood grinding meetings. I've returned to Labin at eleven p.m. and started working on a deadline pressed project with three other developer. We've succesfully deployed the newest application version fifteen minutes ago. Another hour, and I'm crashing and burning into the nearest bed.

What lessons I've learned:

1. Writing at least functional, or just smoke, tests solves much development problems


2. Task development is half of well done feature


3. Regular standup meetings for tracking progresss and quick reactions to changes in the project situation


4. Wokrin in a virtual enviroment saves time and money, and increases the speed a new developer can join an undergoing project


5. Power naps help a lot

What is the motivation for doing a day and a half development sprint? For me is the challenge and the opportunity to be a hero, to save the day. To complete something hard and critical, which not many people can do. For others, I don't know exactly, but I recon is the same as me. I feel downright special right now.

Well I am special. so are my colleagues, we are a special team which completed something special. Nobody can take that away from us.

Sharing your knowledge

Why are developers, and people in general , so prone to entropy? Most of the software developers I know are really quick to throw aways good engineering practices in favor of writing more code. And use the same code writing exercise as an excuse of not doing those practices in the first place.
I have to much work to do! See, how many bugs I have to fix! What do I get from writing all these down, nobody will read that! Testing is stupid, I will be the only one doing it , everyone else doesn't do it!
Oh , how many such sentences I've heard from everyone I talked to. And the energy I spent correcting each and different attitude. Ah! And then to see them fall back to their evil no engineering ways, practically makes me wonder why do I try.
OK, I try , because I really want to teach others what I know and think that should be a practice for all experienced developers, only this way our profession will grow and evolve. I do not gain anything by not sharing and teaching others.
What are the benefits of sharing (for example with your team mates):

• You can shuffle boring and uninteresting work to them, while you focus on more challenging stuff



• You can discuss problems with someone who understands the topic , and possibly made some learning on their own



• You learn by teaching



• People around you will write code with greater quality

Teaching others , or sharing knowledge , has its drawbacks :

• Time spent teaching others is not time spent on improving you


• Teaching others (in my experience) often diminishes your knowledge in the eyes of others , since for them is so easily gained


• Teaching is a strenuous and continuous process with unknown results (if you want to see big bangs for you bucks quickly, better be ready for disappointment)

And the greatest truth of all: you can't force people to really learn and implement that they are not interested in. Especially if you do not a rifle on their heads.

Document first , document later

There is a great debate in my head, what is best – to document first , or to document latter. The wanna be engineer in my head would scream “Document first!”, but my practical side, the one that has been into the trenches, that has seen things, horrible things would say “Document later!”. How to reconcile those two opposing views?

Documents can be generally be placed into two broad categories, those that are:

• Generally written before development


• Generally written afterwards development

Why do I say Generally? Because in software development nothing is set in stone, and everything is fluid, thus documents cannot be said to have been written always before head or afterwards a piece of software is developed( class, module, library etc.) . A set of documents could be generally written before head, like requirements or the high level architecture, and some are generally written afterwards like in some cases detailed API technical specification.

What makes a document fall into one of the two general categories. Two things :

• Type of document


• Current state of the software life cycle

The Type of the document generally dictates when a software piece will be written. Like, requirements or the functional specification or something like that which is generally needed before a piece of software is written. And some which cannot be (or can, but albeit very hardly depending on the skill of the developer and the knowledge of the system), like detailed technical specification which is not ever accurate when written first and is ever (hopefully) updated once a particular piece of software is written.

The other most contributing factor is the current state of the software life cycle a team find its self in. When developing a green field software it is generally best to do the documentation first ( I'm not discussing waterfall here, you could develop module after module, and before each module write the technical documentation for it before going into development), but when a team finds it self knee deep in a brownfield development project, which generally doesn't have any documentation what so ever, which isn't even commented properly so you cannot generate an API spec automatically which is remotely useful to anyone, when you need to fix unknown defects, when you need to implement a piece of functionality and don't know how to place it inside the project and how it is to be connected to everything else, writing documentation first could be and exercise in futility since you don't know enough about the system. This will change gradually during brownfield development when you will reach a state where writing design documentation first would be a better choice in terms of quality of work and writing speed place into the construction of the document.

So, what to say to may two different parts? It depends. And that is the only answer I can give them, which places my little self once again on the verge of a nervous breakdown due to over thinking so simple things. But documentation is important, some cannot see that, but those cocky bastards will soon find them selves trying to remember how they did that, or where somebody placed this and how is generally this implemented and so on, and will loose valuable money debugging the thing out of its life in order to find something which would take five flimsy minutes to read. Who is stupid now, ha?!

14th SQL/DEV User Group Meeting in Rijeka Review

I must say it was an interesting trip. Me and my team went to Rijeka yesterday to attend the 14th local SQL/DEV User Group Meeting. We took a company van and proceeded along the eastern Istrian coast to Rijeka. It took us two hours due to extensive working on the repair of the road and hordes of tourists enjoining the scenery.
We arrived an hour latter than planned.
The meeting was held at the "Naval University" of Rijeka. There were around fifteen to twenty people mostly from three to four companies including our own.
The entire event had some good and bad sides. I'll categorize them .

The Good

Interesting and friendly crowd. We all were welcomed there warmly, and the fact that we were the new faces there made no difference. The MVC talk was interesting, rich with data and the speaker was well informed and mostly good. I met Aleksandar Zgonjan of Pro3x there. After the presentation we all moved to a bar near the train station and had a drink there. I met several persons there including Jasmin Ćelić the president of the local programmers guild. We discussed the possibility of met organizing a presentation there.

The Bad

The technical equipment did't work. The projector malfunctioned or it didn't work with windows. I don't know. We started the presentation one hour late when Hrvoje Hudoletnjak brought a new one from work. Because of the that the IronRuby and Ruby on Rails presentation was not held , which was a shame for me because I was interested in it.

Conclusion

All in all it was a good day. Rijeka is a fantastic city, full of life and history. The most fascinating thing was the torpedo exposed in the courtyard of the university. A historical note : the first torpedo was developed in 1905 here in Rijeka in the factory "Torpedo". I touched the damned machine , examined it head to to toe and event fearfully knokced on its point a few times.

14th SQL/DEV User Group Meeting in Rijeka

I'm thirty minutes away from a trip the fourteenth SQL/DEV User Group in Rijeka. This time its a corporate spornsored trip. Five other colleagues are going with me. We managed to gather up a big van with air conditioning and, event , a corporate sponsored meal. Nice.

The SQL/DEV user group meeting will be organized in the Nautical University of Rijeka and will be composed of two lectures :

• ASP.NET MVC development practices


• RubyOnRails, Ruby and IronRuby for .NET developers

And of course, after the presentations a gathering will be organized with drinks and snacks with all the attendees which will be an opportunity to meet new people and learn or discuss about interesting ideas and technologies.
I really think these type meetups are important for a developers advancement, since you can learn and hear about development use cases which would normally be hidden from you.
I started thinking about organizing a presentation for the next OpenCoffe meeting. Something short, maybe half and hour long, and interesting. Practical, maybe event daring in the specific way I conduct all my presentations ;)
I haven't decided anything yet. I was wondering to do something on the following themes:

• Web UI testing and automation


• Web portal development process


• Drupal theme development


• PHP Unit testing


• Building an MVC framework in PHP.


• Workflow Foundation


• ASP.NET Data binding controls

Don't know. More that I think about it I realize that I know squat. Maybe I should just cover and listen to wiser heads talking.

Overworking it, a bit

Its five past five in the morning. I'm literally sleepless. The amount of work I've been doing recently is crazy. I've been at work for twelve to fifteen hours a day, plus we had two all nighters (twenty three hours of software development in a stretch). And, of course I've had the added bonus of leading a team or two during that time, so it added up on my burn out status.

I'm a wreck.

I rose early because I'm going on a business trip to Zagreb for a meeting with a client, and then to Ljubljana for another meeting with a colleague. Wow! What a trill.

I'm so wasted.

The tiredness is not a problem. I'm coping very good thank you. It's my learning that the problem. I really neglected my studies for the past month. Yesterday I finally finished "Pro WF" after six months of reading. Stupid. Once I read a development book in two weeks.

I must pick my pace or I will be crushed by younger, more time free forces.

The sun and the way UML diagrams fold on my freshly inked skin

It is my firm belief that any modern developer, being junior or senior needs to know at least the basic of UML 2.x class, sequence and activity diagrams in order to be productive in his workplace and to communicate effectively with his coworkers about one of the most hard and abstract matters known to man, by which I mean the matter of software design.
But what I find in the field today is sorry state of affairs where the majority of developer are not aware that UML even exists, a small percentage of can read it and only a handful can write and express them selves in the fine software modeling language of UML. It is my opinion , as a practicioner of the craft, that each high school that teaches programming and each university that prepares young feeble minds for a career in IT or software development must teach its students the basics of reading and writing of UML.
UML is most critical to understand object oriented design. When a developer is able to express his idea about a system in uml , that developer shows a deep understanding of that idea, and therefore is able to teach to other, implement it by producing qualty code and adapt it to changes which are sure to come in the future.
Code which isn't described by UML (or any other notation for the matter)is hard to read, hard to teach and hard to change. Code that is described by UML isn't any of those things.
But by the God of Chips and Neurons, UML isn't hard to learn either. You just need a manual (e.g. UML distilled by Marting Fowler) a pen and sheet of paper on which you can sketch your first diagrams. I've learned my UML near the sea in Pula where I live. I would put the Fowler book in my backpack, take a notes and a black 0.4 pilot pen and I would venture on foot the Pula's "long see" (lungo mare) a walkaway for tourists and kinds high on booze and midnight sex , and I would sit there by the see and draw my diagrams watching the sun go down deep below the summer sea and enjoy my self learning a powerful tool which made a better developer, a better person and more ... I don't know.. just better than I was before.
That should be enough for any of you sorry asses who haven't had the time to learn a tool as basic as UML.