Open Space Offices

Well, I was changing my mind about whether open space offices are good or bad few times already.

But now as I tried this, that and that my opinion established into solid idea.

Open space in no way helps to gain the pick of productivity. You can argue with this but I don’t give a fuck to this.

I am not about to state that each employee (developer) should take its own room. That’s would not be productive as well.

Small rooms for small teams seems to be the best.

But separate room seems the best choice for me personally. Just I am able to do the most during a day.

For those not able to use their brain efficiently I will use figurative language: working in an open space is like living in a hostel. Wanna work in open space ? – sell your house and go live in the hostel.

Do You Really Need To Be 8 Hours In The Office?

This Dilbert strip

unproductive time

made me think for a little on questions like

• what is productive and unproductive time?
• how long should you work everyday?
• should you keep to the rules like working day start/end hours?
• are you an example for others?
• should you screw your subordinates up if they are not being at their desks precisely from X am till Y am?

I have a very short answer for such questions: IT DOESN’T MATTER WHEN YOU COME TO THE OFFICE AND WHEN YOU GO HOME. UNTIL YOU PERFORM EQUALLY/BETTER THAN OTHERS NO ONE CAN POINT THIS TO YOU. IF SOMEONE DOES – TELL HIM “FUCK YOU”

We are not living to work, we are working to learn and have fun, to create. Let people working in fastfoods/banks/receptions/etc. be a slaves which should spend 8 hours every day believing this is very beneficially for the society. Good people should try to manage their life to spend as less time on routines as possible and to leave as much time for learning new things as they can.

Be Careful with Renderers

After we added one fancy renderer to ADG to highlight our search results in case user performed a search I noticed that vertical scrolling slowed down way too much.

After some investigation we found the culprit: in case when no search was performed the renderer filled the cells with white solid fill using beginFill() and endFill(). We substituted this to just graphics.clear() and everything was fixed. So it appears that beginFill() – endFill() is quite expensive though primitive operation. Not funny

FX -> SL

It seems to me folks that I will start mastering Silver Light.

I’ve invested few hours of my time just to read as much of possible forums, etc. as I could to see what community is thinking.

Multiplying it by everything I’ve heard from the guys I’m working with the conclusion is to install all needed staff and start coding for SL. Seems it is already mature enough for not being a headache.

Mate: Drinking and RIA Development

It happened almost at the same time when I introduced myself to Mate-as-beverage and Mate-as-Flex-Framework

Both things are good stimulators. When you drink Mate it is a kind of a ritual, not just like you buy a bottle of Cola and just drink it. To prepare a good Mate you need to put a piece of your soul and some good thoughts into it, not to say about technology: the water must be of a particular temperature, you should know how much Mate to put in, how to pour water into it, etc. etc. When you done it well you are relaxing, your friends are relaxing and everything is just fine, everyone enjoys a good drink. If you done it improperly people will drink it, they will tell you it’s tasty but they will think “what the fucking crap is it?” ))

The same thing with Mate framework. Proper developer armed with Mate will make the design simpler and cleaner. When applied in wrong way it can make the application heavy and hard to understand. After few monthes of sometimes hard work I have something to summarize and say on this framework, maybe this will be helpful for some readers:

• the first thing to say: coding with a framework is more productive then coding without one. This is true in general and true for Mate. If you don’t agree with this – go and code for some bananas.
• Mate provides a variety of weapons that are nicely arranged as MXML tags. After you’ve become friends with few of them you can intuitively understand all others since framework is coherent and consistent. The latest thing I think is due to the fact that Mate is writen by a very small team and the core is actually written by a single man: Nahuel Foronda.
• As it would be real damage for your body if you drink liters of Mate each day and if you don’t drink anything else the same damage will occur to your application if you use Mate here and there without a mind. I went through it and I know what I say. Do not use Mate if you can do simple things inside your single class. Do not overcomplicate the design. I mean if you can dispatch and catch some minor helper event inside the same object you should bypass Mate event maps.
• Now about drawbacks. I encountered only one real drawback but in my case very important one: if you need to generate some models/views dynamically whitin the life-period of one swf and if you need to remove such views from the display list and substitute them by fresh ones you can go into trouble. The troubles will happen if you use injectors. Though the Dependency Injection is real power allowing you brain to not control each and other step in your algorithms sequences it creates a lot of bindings which  you can not delete in case you are removing your view from a display list.  So no matter how thoroughly you clean up your models/views that you don’t want to use anymore, no matter how many variable = null assignments you will do almost everything handled by those bindings will remain in memory and not GCed.
  Though still Mate can be used in this case: just without dependency injections. You still have EventHandlers, MethodInvoker and DataCopier workhorses that can save you a lot of time.
• My next thought may sound a bit heretic but I decided to keep the rule: minimize number of injectors in your event maps. Almost everything you reference in Mate xml constructs you reference by class names, not by some ids of concrete instances. So this rule pretty implies that you need to minimize the number of classes you are referencing in your event maps.

In general: Mate should and can be used for real applications development. I am sure that each developer using this framework will serve his own unique flavor of the Mate with its own taste. And this is very right thing: we are all different so why shouldn’t we do different code :p

When I decided to use Mate in my application I didn’t know ANYTHING about it, just have read some websites with different people impressions. But I decided I will employ it anyway. Now I have a framework in my pocket but the pocket is large and there is still a lot of place

UPD: More than half of a year passed from the time of this post publishing and today we upgraded Mate from 08.5 to 08.9 version and it seems like some memory problems will be resolved. Have not yet seen it by my own eyes, so will test after daily build and then confirm. If so then it would be a strong + to Mate.

Three things I can endlessly contemplate

So, there is a saying that there are three things you can endlessly look at: water, fire and something else, I don’t remember )))

I would rephrase this saying for IT people, especially for PMs: I can endlessly contemplate 3 things:

- how QA post bugs
- how developers fix bugs
- how QA close bugs

Consistency vs Choice

I would like to share in this post one of my conclusions based on the projects experience.

It is very common situation when something can be done in more then one way. For example, you can have List screens where some lists of items are shown. And you can have a small feature there: search by the item name. There are at least 2 distinct ways how you can design the interaction:

1. User types in a part of name and then clicks some button or icon. Search is applied then.
2. User types in characters and as he types the list is continuously being filtered

The question that will definetely appear at some moment is which alternative to follow.
Some people can just not notice this fork and will implement some default solution. This way is not good since there is 50% probability that your users will ask you one day “Hey Jack, why didn’t you choose the other way?” and you’ll need to redo.

If you are more smart you will smell the fork and will ask your customer beforehand: Hey John, how would you like this to work?

That will work but still this is not the best solution.

The best one is to have in your application 2 similar List Screens and implement one way on the first screen and the second one on the second. Then leave it as it is. Let the John-the-Customer touch it, play with it and he will come to you one day and select the solution fitting his needs the most.

You may think there is something wrong with such approach, a need to do double-work, but it is easy to smooth out everything when you have different versions. It actually degrades the probability of those 50% when John ask you reimplement the stuff in absolutely different way.

To sum up the bullshit above: consistency always wins the battle through the powers of choice

RefUcktoring

I should have been in the mountains today and tomorrow and should have been having fun on my snowboard but this night when time came to get up and pack my things I felt that my throat is a bit ill and decided (it was not easy) to stay at home.

What one have to do when staying at home on weekend. I prefer learning, blogging and drawing This time I chosen to write about refactoring, more precisely about my approach to refactoring.
If you’ve been boiling for some time in IT soup you should know a lot of cases when you or your team needed to refactor some complex system. You are lucky if you have the man who built up the current version of the system to do the job but in a half of cases it will be just a dream. In such cases whoever will take the task should be able to:

1. Analyze
2. Plan
3. Implement
4. Test/Debug
5. Fix/Finalize

If the person is not capable to perform any or few of the listed parts of the task – then your project is in trouble.

So, in my project the last week was very hot one since it was last week when we could increment functionality, the next few weeks period will be stabilization phase. And the customer wanted us to improve performace of one thing which required a major refactoring. Not to say that we didn’t knew earlier that the bloody thing should be refactored. We knew that but there were a lot of other tasks + speaking honestly noone wanted to do that job since the guy who initially implemented the complex module (he did this well taking into consideration requirements at that time) was no more in the crew.

But like it always happens the customer insisted and there were no choices but to roll up the sleaves and quickly do the job. I estimated it roughly to 5 man/days.

My programming experience is not that much but I had few times before to lead some difficult refactoring as a manager. And each time I applied the same tehnique which always proves to be good:

1. Analyze
2. Plan
3. Implement
4. Test/Debug
5. Fix/Finalize

For points 1 and 2 you need anything where you can draw some simple diagrams. I use a kind of mind-mapping diagram where I try to desribe at the first level basic tasks definitions, then as the branches everything I know about the problem (but only needed things) and points where I need to research, then on the next levels concrete tasks that I need to implement to get the thing done. This is a very good materialization of the analizys process. All tasks that I need to implement I mark in a red font to have them sharply visible. It looks like this:

I always keep there only needed info, names of the classes, code snippets, etc.
When I feel the analysis is completed I start the point 3: implementation going from top to the bottom of the diagram. When a particular red leaf is done I mark it with green background. I do some small tests after each step and when all is green I start testing and fixing small things that always definitely shows around.

I completed the task in 12 hours almost without any breaks, even missed my lunch. It was interesting and it works
What I actually implemented is incremental loading of data and its caching. Now I know how any abstract caching is done technically. Think this will be useful in future. Big thanks to Max Hryniv who’s code teaches me a lot.
Also I’m not sure that this technique is suitable for everyone. I saw a lot of times when guys skip steps 1 and 2 and start right from the step 3. But almost always it results in UNDERestimation and troubles.

2 brains are better than just one

I haven’t been here for a while. Just was too deep in my work and only today allowed myself to take a look what’s going on in the blogs of my friends and make some comments.

Because today was a really good day. In my current project I have a release on Monday and still in my favorite (but most complicated) module there are few really dirty bugs that makes this module to look not that nice as it might be. I came today to the office somewhere at 3 PM with a strong intention to fix one of the problems and a belief that I can really to this. My current understating of Flex allows me to analyze almost any piece of code written by any developer and make there needed changes in case of trouble. I’m lucky that all guys in my team are quite autonomous and can take almost any task by a simple input (sometimes I use a sticky yellow note, write there a short description and stich to the guy’s table) and start working on it without disturbing my concentration on some more difficult thing. So thank you guys for this, I love you all.

There’s a one good mate in my team, Max, who is my primary force for that module development. I worked out few necessary management thigs and then we sat together with Max at my laptop and 4 hours were analyzing, debugging and fixing a trouble. We won. I realized this day few very important things:

• there are tasks in software development that are unarguably better to do with a friend, not alone. I would not be able to fix this bug without Max, definitely. And he was not able to fix it without me in few previous tries.
• sometimes quite simple (at the end when you find it) problem can cost you really a few days of work to fix.
• even BEST, ingenious developers mistake
• fixing bugs can be just a good quest, a good game and a lot of fun if you perceive this activity positively
• diagrams and visualization of complex activity chains helps invaluably when you try to understand a complex mechanism created by other person. We created a set of sequence diagrams for different functional flows of that module and then benefited a really from having this before our eyes. Max really cool in doing this, he showed me that Enterprise Architect can import Flex packages and convert it into workable items in diagrams. Once again I appreciated how good tool EA is.
• sometimes you need to sacrifice personal life and some fun to get the things done at your work. Today I planned to meet one girl, an old friend of mine, who I have not seen for a while. But at 6 PM I was still in the middle of the task so I just called her and told “Sorry baby, we can’t meet today, I have a work I must to do.” I felt that this was not a thing she wanted to hear but she’s a good friend and tomorrow will be ok.

So: if you see that some person in your team can’t do some thing despite of working hard on this – go and help. If you trying to do something and it doesn’t gets working – go and ask for a help.

Minimalism

After few monthes on my current project in result of situation and advices of few guys I’ve understood and accepted a kind of “minimalism” mindset.

You don’t need 3 colors (green, yellow and red) to indicate the state of parts of your project scope, really. You need only 2: green and red. When results are needed it always ekther “working” or “non-working”, “sellable” or “non-sellable”, you can go to customer and show it or you can’t.

The same goes for “done”, “not done”, “in progress”. You need only “done” and “not done”.

This is the essence of delivering and result-orientation.