31 August 2012

Atari Lives!

 

Just a quick post for me. This morning I was checking what was cool and new at Microsoft and found this cool blog post about Atari games being redone in Html 5 for the browser and the Windows 8 table .

Check this cool blog post about it (there is an event cooler video).

And of course if you want to forget .NET, Objective-C and Java you can go back to the future and be an Atari developer here.

01 July 2012

Good bye Novatec, welcome Cenosco


On April 28th 2008 I was the first engineer that was hired by Roberto Gobo, the then and currently active director of Software Development, at Novatec New Technologies. And now, four years and almost two months later on July 1st 2012 it will be my last day at Novatec.
I will leave my position of Technical Lead which I continuously held since the beginning of my work there. I worked in many different technologies, in many different domains and for many different client. I worked with small teams, with big teams and sometimes solo. And it was quite a ride.
But it is my time to leave and start something new.
In July I will start my work with a Dutch based company Cenosco in the role of a Software Architect and I really look forward to that.
So goodbye to my mentor and friend Roberto Gobo, my good colleagues with whom I’ve shared laughs and perils and hope I will meet you and work with you again, but not just yet this year :) .
What are the best lessons learned from my spent at Novatec:
  • -         Write down every meeting with the client, share those minutes as references and they will come handy when change requests are being negotiated
  • -        Use you issue tracker for storing everything: tasks, issues, change requests and defects. Your issue tracker is your best friend for storing software requirements.
  • -        Write you architecture in as short a document as possible using as many pictures as you want.
  • -        Be gentle with people you work with, bend and do not be stiff you will get more done
  • -        Technical knowledge starts projects, relationships finish projects
  • -        Do the most important thing for the client first
  • -        Do the most important thing for the project second
  • -        Find time to increase software quality attributes
  • -        Teaching people takes time and effort, if you spend it will save money later.
  • -        Learn, take time to learn on and off your job. Use whatever podcasts in your car, book, your kindle for reading articles, presentations from the web and you own coding katas.
  • -        Connect with you peers in other companies.

When all is said and done I’ve done a great job there. I’ve trained a lot of people, I’ve done a lot of projects and helped creating the technical culture of the company.
I will miss it but it is time for something new.

15 June 2012

What is technical leadership

Use Case Model

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.

02 June 2012

JavaScript inheritance

 

There are many ways to do Object Oriented Programming in JavaScript. And there are multiple syntaxes for creating object inheritances. Given the fact that JavaScript is a functional prototype oriented programming language the classic inheritance pattern and syntax is not actually something which is on the top of the list for most JavaScript developers.

But what if your team or you are classical server side developer and are well versed in the Object Oriented Inheritance model found in Java, C# or PHP and you need to develop a JavaScript based RIA application?

Well there is a JavaScript inheritance model which is simple and is similar to the classic inheritance syntax used by more server oriented programming languages. Of course in JavaScript we don’ have private or protected methods but there are ways to handle that. What is important is the ability to create a proper inheritance tree in a very simple manner.

The basic inheritance story looks like this:

   1:  function User(){
   2:   
   3:  }
   4:   
   5:  User.prototype.Authenticate = function (username, password) {
   6:      return true;
   7:  }
   8:   
   9:  function Clerk(){
  10:      User.call(this);
  11:  }
  12:   
  13:  Clerk.prototype = new User();
  14:  Clerk.prototype.constructor = Clerk;



The class User is a basic class with a single method Authenticate. The method Authenticate doesn’t do much. The class Clerk inherits from the class User. The basic inheritance pattern is this:


   1:  Clerk.prototype = new User();
   2:  Clerk.prototype.constructor = Clerk;
 



 

The prototype of the class Clerk receives a new instance of the class User. The constructor of the class Clerk is reset again (since it was overridden in the previous call with the class User) to Clerk again.


Thus the class Clerk has now all the properties and methods of the class User. In the constructor of the class Clerk we call its parent constructor to initialize any constructor initialized properties or activities.


   1:  function Clerk(){
   2:      User.call(this);
   3:  }



The first parameter of the call function set the context of the this variable in the called function. With this line now the this in the User constructor is no longer the User class but the Clerk class.


The above example is the bare minimum you need to use in order to have classical inheritance in JavaScript. The next example will deal with three advanced concepts:



  • Method overriding

  • Passing parameters to the base constructor class

  • Calling parent methods in overridden methods while conserving the this context

   1:  function Institute(name){
   2:      this._name = name;
   3:  }
   4:   
   5:  Institute.prototype.getName = function() {return this._name;}
   6:  Institute.prototype.setName = function(name) {this._name = name;}
   7:  Institute.prototype.educatePeople = function(){
   8:      console.log("The instititute " + this._name + " will educate 200 people this year");
   9:  }
  10:   
  11:   
  12:  function PrivateInstitute(name){
  13:      Institute.call(this,name);
  14:  }
  15:   
  16:  PrivateInstitute.prototype = new Institute();
  17:  PrivateInstitute.prototype.constructor = PrivateInstitute;
  18:   
  19:  PrivateInstitute.prototype.educatePeople = function(){
  20:     Institute.prototype.educatePeople.call(this);
  21:     console.log("And we will earn mucho dinero!";
  22:  }



In the above example we have two classes the Institute base class and the PrivateInstitute child class. The Institute class receives one parameter in its constructor its name.


When inheriting the Institute class the name parameter is passed to the parent constructor after the this parameter in the call method like this:


   1:  function PrivateInstitute(name){
   2:      Institute.call(this,name);
   3:  }



Both classes the implement the educatePeople method. The version in the PrivateInstitute class is a simple override. In order to override methods in JavaScript we just need to repeat their names and the that version will be used instead of the parent method. But what is we need to call the parent method, or a method belonging to a different ancestor in the inheritance tree? Well the syntax for that is a little different. We need to call the method on the prototype of the class of the ancestor we are calling the method on and as the first parameter we need to pass the current object instance like this:


   1:  PrivateInstitute.prototype.educatePeople = function(){
   2:     Institute.prototype.educatePeople.call(this);
   3:     console.log("And we will earn mucho dinero!";
   4:  }



Normally as was the case in the previous constructor example if the ancestor method receives any parameters they are passed after the this reference in the call method.


There is one further things one needs to be very carefull and is the this context in DOM event callbacks which reference to the DOM element being operated on. The following trick makes all the this pain go away.


   1:  SomeClass.prototype.callbackMethod = function(event) {
   2:     console.log(this.SomeProperty); //printing property belonging to the same class
   3:     Parent.prototype.SomeMethod.call(this); 
   4:  }
   5:   
   6:  SomeClass.prototype.UIHandler = function(){
   7:     var self = this ; //alternate name for this
   8:     $('button').click(function(event) {
   9:        self.callbackMethod(event);
  10:     });
  11:  }



The main focus is the replacement of the this variable with the self variable in the scope of the method. The self variable in the callback of the click event handler is the SameClass this context thanks to the closure feature of JavaScript.

02 May 2012

Ramblings about life and software in general


“Good news everyone!” , said the nutty professor in Futurama. And good news indeed. I get to talk another year on the Case24 software engineering conference in Zagreb. And I'm the first talk of the day with my talk about “Agile architecture with distributed teams”. And the time I have to talk about this really big topic is around 30 minutes. When I talk about this it usually takes me around 2 and half hours to scratch the surface.

I plan actually to focus on the key getaways I learned about working with distributed teams and agile architecture. In 30 minutes it is the only thing someone can really tell.

Fortunately I get to also write a paper on the topic in which I can get in more deeper in the problem space.

Software developers really should write more. It is a skill rarely seen in the software cummunity. Really, who of you guys writes regular documentation or event writes something which usable or even re factored or reworked as the project progresses? A really small number of people really.

But without good documentation we cannot do our work. See PHP or .NET for example both good examples of documentation overflow. You can learn PHP only from its manuall and on MSDN there is a ton of things about which ever way a specific class may be used. Java on the other side didn't really made be fuzzy and worm inside with the state of its documentation.

I've started refocusing on .NET lately watching BUILD presentations, reading about some new things doing my katas with .NET and Mono code. And was really taken aback in the difference of the quality of learning materials the basic platform documentation has for .NET and Java developers.

I've done a small 2 day Java project lately and it was Google/Stackoverflow all the way. I'm working on a PHP project currently and its is only the PHP manual by good that is the best piece of documentation I've ever seen. It is so freaking useful , a shame PHP is littered with problems as a language.

Of course .NET has a problem of its own , its like a flood. Microsoft really is getting a ton of things out if its development engines out into the world and you need a real control mechanism to stem the tide of information if you want to survive the day. That would explain some of the behavior I've seen in some .NET developers which can be described simply as “Ok I learned this, and I will stick to as if its the only parachute in the airplane and it is about to crash. “ Getting some of those guys to try something new or change paradigms is really, really hard . On the other hand I've see a lot of PHP guys with the attitude “Oh God let me learn and try something new, it is is so cool and so easy I just want to pile so many new things.” The few Java developers I know are mostly silent guru like types who for any problems just say “It is not a problem”. I do not know what to make out of those yet.

As a general rule more if more things are written and maintained around a technology the better, but if too much is written people will shun most of since they really cannot catch with everything and do something productive at the same time.

I've just started things what is the difference in the effort of training someone in .NET and PHP. I've done both. I've trained people to work in .NET (ASP.NET, C# , SQL Server, Nunit, Javascript) and PHP (PHP, MySQL and Javascript) and it is easier to train a complete newbee in PHP then it is to train the same person into .NET. It also takes longer to train someone to work with .NET. I think it has to do with the fact that .NET solutions have more complex code bases then PHP solutions with the same functionality implemented (lets face it .NET is more rigid then PHP and you really need to type more code to get some things done).
On the other hand you can be a better engineer with .NET since it enables you more clearly design and develop your system then PHP. PHP is more liberal and chaotic and while you can make good design and engineering work with PHP it takes more effort and is harder to battle entropy then it is with .NET. Of course bad coding is bad coding and no language can replace it. But given the fact that more effort needs to be spent in learning .NET then PHP I think some people just give up, or learn good practices or just raise more awareness around things then before.
It was just so with me. I've started as a PHP developer and then after a three or four years of constant PHP development I've switched for around a year of Python development (still do it some times) and the for four years of .NET work with mix matching PHP work. And it changed me. It really did.
I've transferred my PHP skills and way of thinking around the code to .NET , saw that some things do not work that some things do work and then I've returned to PHP with .NET experiences which I could transfer and apply to PHP projects. Like energy regardless on the platform or language you are working on nothing is lost, knowledge just changes state.

Life is complicated, software development is complicated as hell , it is not easy and it is not pretty but I love it none the less just as I love life and my family. To me being an architect and technical lead or just a developer is natural like breathing and cannot imagine my self doing something else.

28 April 2012

Surviving a distributed software development team


There is an art intrinsic in working with distributed teams. There is also an art in surviving working with distributing teams. This is an article which deals with the latter, the unsung and the unglamorous skill and craft of managing day to day survival working with a distributed team.
The core skill one need to have is relationship building. None other will help you in you daily work. Especially if you want to be great at it.
Why? Teams are group o f people. For a group to function people need to have good relationships with each other. If people are collocated those relationships build only by the fact that people work closely together. Of course this doesn't mean that those relationships are great, but they generally exists in a greater degree then those which naturally occur with distributed teams. Relationships need work and effort and not many people do spend it. Especially in the IT business.
Now, if you work with a distributed team, especially if you never or seldom met or worked in person with other team members chances are that you are not going to have a great relationship with them. Now, you will talk to them and manage your normal day to day assignments but that will generally be all.
Lets say you have a problem. You fouled something up, or you don't know something. Something happened which doesn't ordinary happen and you need help from one of your distributed team mates. And that help is generally something which will distract that person from their regular work for a couple of hours or more. What will happen?
You call that person, if it is a normal person she will try top help you. For an average half of an hour everything will be OK. Then a full hour will pass and that person will became nervous. And then she will find some excuse to continue working her regular work or she will just ditch you. What can you do? You can try calling someone else or try with escalating the issue to get the help you need. Both will generally not result in happy coworkers. If you call someone else that person will also be distracted from their work and be nervous and if you escalate the issue the person which will be dragged to help you (usually your first call) will not be happy that your superior made a point of noticing their failure with help you with your critical problem.
Just for a moment imagine that you spent some time during the start of the project getting to know your coworkers or just re-catching their life story if you worked previously together. Maybe just talking about their families, helping with their problems, discussing general stuff. Building a relationship.
And when you have a problem you need help with that person will be more likely to step in and help and stick to it because she will help a friend not a coworker.
The other scenario which I encounter and is a problem with distributed teams is getting steel cage death match allies. Sometimes during a project you will get into a team wide, or a subteam discussion about a technology solution, or a problem which needs to be solved, or you just need to defend your work. You need allies, you need people backing you up. If you spent some time talking with people and building a relationship they are more likely to be helpful if a problem arises and back you up. And even more helpful if you spent some time before hand asking a their opinion and discussing their ideas with the topic you are going to have a steel cage death match over. People respond well to being asked to express their ideas and opinions, especially engineers. If you want to win people over in a software team you need to ask them what they think and what they want and respect their ideas.
Now this a fallibility of mine which I some times fall into. I forget to do that, and then I get bitten into my humongous ass. If you are in a technical leadership role you cannot just enforce your opinions and ideas on other. You need to ask them what they think, what are their opinions and ideas. And wonder of all even the most junior person of the team will have something valuable to say.
In software development people and relationship matter. No matter the deadline, no matter the cost, think about the people first. Make your coo workers your top priority. And when the proverbial rear exiting stuff hits the fan they are going to be the people sitting next to you at six in the morning fixing last minute defects on the presentation tier of the application for the client presentation in the morning.
There is one thing I almost forgot to write. Talk do not write. All distributed teams use one from of IM communication or other. If you want to solve your problems fast and build relationships talk to the person on the other side do not write. Writing is good for quick ideas and exchanges but if a discussion is in place you need to talk to the other person, you will see how more quickly you will solve your problem.

12 January 2012

Another year has passed away


Today is my 31st birthday and exactly one year we have started our current project. We are nearing its first major release and are working around the clock to finish it.
In the last year I’ve gotten some experience in large project running with a geographically distributed and culturally diverse team. I’ve also learned some valuable lessons regarding the art and craft of software engineering:
  •   Write technical documentation as often as possible as short and concise as possible, it will save your ass often as not when you least expect it
  •  You have always the time to unit test and refactor your code, it will save your ass down the line
  •   Be open and clear of your expectations, expect to repeat them often and follow back on each critical item
  •   Love your testers, respect your testers, they are your most valued and greatest assets which make your life easier and make the project better
  •  Know your architecture, plan your architecture, and expect to repeatedly repeat it to others in the team
  • Trust your project manager, he will make your life also easier and will make the project better if you let him
  • Trust your team, grow your team , only then your job will get tolerable
  •  Expect to iterate often and always on each item of your daily job
  •  People forget, people are people and aren’t perfect
  •  Trust, respect, understanding go a long way towards a completed project
  • Discuss issues not people or span wars

There is one valuable lessons which I got to understand:
  •  If someone is a value waste on your project and continuously responds negatively to feedback and doesn't grow cut him us swiftly as you would an intruder in your home threatening you and your family because that person is doing right that to your project, your team and your self


And finally:
  • Time is your most valued commodity, spend it well, manage it well.
  •  Find time to read, experiment and learn. To remain effective you must grow even under the most greatest pressure and time constraints.
  •  In time of greatest stress and overworking find time to be with your family because they are your most greatest ally in the face of adversity and your most greatest support mechanism, if you turn your back on them they will turn on you.