Understanding english speech

Hi, I learn english myself and about couple of monthes ago I wished to practice in understanding english speech. Of course, I've googled and there are many resources. But no one was friendly enough for me, so I decided to make one myself, now I did it and published there http://english-player.com.
You are wellcome to play with it :)

Usability group

About month ago I visited usability lection and there are key points.
1. UX professionals show UI prototypes to users before ANY programming. Obviously, everybody else should do the same.
2. Paper is better for prototyping than any software (including Balsamiq Mockups).
3. Very small changes in visual design can make big difference in profit. The only way to find out how to change the design is experimenting with real users.
4. There was a link to http://uxmatters.com – I find it interesting.

Progress report.

Couple of years ago my colleague told me that my code is shit and is not going to improve. For last 5 months I’m told almost every day that my design decisions are bad and project architecture sucks. And today I’ve got new level. Marat Faskhiev told me that I’m extremely bad in project management decisions and never ever will be any better. I can’t even imagine what is going to be next... :)

Rework

I’ve just finished “Rework“ – a new book from 37signals guy. Very cool and very useful. It is about how to work better. After reading it I realized there are things I do wrong constantly. Three is my confession :

I use word “easy” far to often. Others’ job seems to me more simple than it really is. I’ll try to use word “simple” about my job only. If you find me telling you that your job is simple I owe you $5. Seriously.

Next sin is I work too much. Usually, 9+ hours a day without reading news or blogs or something, that’s too much. I do not fill very tired but I want to stop it anyway. Fortunately, my employee does not pay me for extra hours which should help.

And one more thing to think about. I’ve not considered writing as something serious. I write this blog like a small game with myself. Alex Yakunin once advised me to write something more useful than posts like this one. Probably, he was right.

Why visit events?

4 days ago I visited a local conference called “Agile days” where team leaders from different companies explained which agile practices they use and why. Of course, nothing has been said you can't read in books and articles in the internet. It is always so. Obviously, that’s why 80% of my colleagues do not visit such events. So it seems to be an interesting question Why I’ve spent my time and money if I could have not ?

Surprisingly, knowledge is not what I was looking for. Real profit events like this give is energy. All good speakers radiate positive and creative energy. It is a psychological phenomenon - when one passionately tells you about agile practices it gives you charge to do something about it. It does not mean you turn into scrum master next morning but it helps to make a step forward.In my case it was enough to have a look at new issue tracker and even to start using it. Moreover, may be I’ll agitate my teammates for scrum meetings or something.

How to layout forms?

There are many simple rules to follow designing forms. For example, logically related fields should be located near each other, most important fields should be visible at once when form is opened and so on. In this post I would like to share my personal preference for how form fields should be arranged. In fact, it is easer to express using images than words.

LiveUI postmortem

Had an interesting experience yesterday – I’ve opened LiveUI project after 3 month's pause. (Project is dead frozen since January). And there are several lessons I’ve learned. First one is: It is difficult to develop a framework and have a fresh look at the same time. Now I see many mistakes  I did not notice earlier. The biggest one is that it solves too many problems. For example, LiveUI provides special infrastructure to make sure client side objects are disposed correctly. Now it is obvious to me that 99.99% of ASP.NET developers do not care about memory leaks at client side and therefore feature development was not cost effective.

So, how could features like mentioned one be implemented at all? The reason is that applications we developed using LiveUI needed these features and it seemed natural to include them in a framework. (we developed LiveUI and used it in parallel). Unconsciously I followed the pattern – If feature has nothing to do with specific business logic and can be implemented as a part of a framework then it should be implemented as a part of framework. It was foolish and that’s why. When you implement a product for some customer then cost of feature is just cost of its implementation but when you develop a framework it is much more expensive. Firstly, because API reviews, documentation and samples take time, secondly, because it makes framework more difficult to learn. Every public class and every public method kills simplicity which is precious resource. Once it is written it seems obvious, but, unfortunately, it was not.

So there is the second lesson I learned. What I had to do was to split projects in groups like these:

Framework

Common code for applications

Application A

Application B

Application C

But our project structure was

Framework

Application A

Application B

Application C

As a result, framework included too many features and was not finished in time. May be, in the future I’ll find time to throw away 60% of LiveUI which would make it finished at once :)