Is the Quality Important?

-We’ve made quite a big effort to improve quality of our services during the first half of the year.

- I don’t believe that improving current quality of services can leverage on wining new deals.

- We wouldn’t have had a chance to renegotiate our support agreement unless we had improved the quality.

- Although your approach is nice, customers are never willing to pay real money for that.

- We wouldn’t have won the new deal without references and we wouldn’t have got references without very good opinion about last implementation. That’s real money.

- I don’t consider that as essential in the deal you’re talking about. And I repeat that my experience shows that customers won’t pay for quality improvement.

- I definitely don’t agree with you, but that’s the discussion for different meeting.

What’s your approach?

Technology for Web Applications

If I was about to start a new software project it would definitely be a web application. A couple of years ago I was building a team creating ERP solution from a scratch. If I had to choose one thing I’d change if I had a chance to start whole thing once again I’d go on-line instead of creating a classical desktop client. And yes, I remember that two years ago web technologies wasn’t so mature they’re now, even though I wouldn’t actually call them “mature” yet. On the other hand now, after two years of following that path it would be a great advantage over competition. Especially when we talk about SME segment of market and multilingual application and that was exactly our target market back then.

When I think about that and I recall all those users I had to deal with when I was support team manager in CDN XL team I believe we’d have to address all major web applications issues. OK, maybe graphical design wouldn’t be so crucial, but speed, contexts, and keyboard-driven steering were on the list. The technology should have been chosen carefully.

A little side note: time when I was an active developer is rather ancient, so I my look at technology is based on what I see developed by others. I don’t say something is definitely impossible with any particular technology, but I believe that there have to be some reasons why (almost) no one makes very good/great applications using the technology. Another little side note: when I look at application quality I consider several factors independently, so I can imagine e.g. great usability combined with poor functionality. Of course overall outcome won’t be very impressive that way.

Coming back to hypothetical technology choice on the end of 2004 I would probably opt for Flash. It loads long, but that’s a single time investment. After that it can work instantly. In terms of speed, when something is efficient in games it will be enough in business applications too. With fully controlled working area, made entirely from your own “controls” contexts shouldn’t be a great problem. I don’t say it would be easy, but I guess there’s no serious technical barrier to achieve that. You could also ignore standard keyboard shortcuts from browser – you wouldn’t have much use of them anyway. A great graphical design wouldn’t be a problem either.

I don’t say that from the technical perspective it would be easy. You don’t see many business applications made with Flash around. The alternative is placed in different AJAX technologies. However, when I look at AJAX applications, they never let me forget I’m using the web. It does mean that despite having all advantages on-line apps provide out of the box (collaboration!) they lost competition in usability category.

I haven’t seen any Flash Application Framework, but I guess we’ll soon see one. The other way is to find universal solution of usability issues in AJAX, which is far easier to use than Flash (basing on number of existing applications). If I had to bet I’d probably go for the former solution, although it can look as a weird idea.

Calm Down

You’ve read an e-mail. Someone has really pissed you off this time. And I mean really. You start hitting you keyboard with all the anger you have inside, typing the “fuck off” type of answer adding all hidden and unhidden grudges you held against your adversary.

Stop! Calm down! Now!

Leaving the thing as it is – unanswered – gives you nothing. But that’s perfectly OK, because entering the discussion on that level can only harm you. You can earn a couple of new enemies, you can say a bit too much and you can deepen your frustration. It’s a bit like with Dilbert and Pointy-Haired Boss. Every time Dilbert stars the discussion it ends up with Boss hating him more and Dilbert exploring new levels of his frustration.

Yes, it’s so hard to ignore attacks on you, and these are attacks indeed, but most likely you’d be trying to talk to deaf people anyway. You could scream your lungs off and you’d see virtually no effect.

I know that it’s really hard to follow this advice. I know it, because personally I failed here way too many times.

Team Management: Find Your Way

As you probably know, my view on management is rather classic – nothing very far from whatever you can find in a respected canon. I’m against micromanagement, but I try to care about details which are important for people. I try hard to be honest with the team and praise them when they deserved. I believe good performance reviews are important. Just old-school, boring management techniques.

I believe that’s the way the whole management thing should be done. However it fascinates me every time I read about Bill Gates’ style of management or One Google Management Way.

Bill, the builder of the greatest company in nineties was considered as bully and the one above isn’t the only example. OK, you can find a lot of bullies in high management around, but somehow many people in Microsoft saw in there a way to improve people’s performance. Everyone had to be superbly prepared, ready to discuss every detail of their opinions and able to resist pressure. Bill’s charisma was essential in building company’s power and his attitude was an integral part of it. You can say it’s weird and it doesn’t work anywhere else, but with Microsoft results speak for themselves.

When you take current decade and look for its symbol you probably see Google. And you see another strange approach to management. More than 50 people in teams, when 7 people are considered as the optimal group to manage. Famous 20% of time for pet projects. Extremely tough recruitment process with more than 7 meetings on average before hiring. Engineers as sacred cows. All of those, and many more, combined in one place create unique management culture, which is against anything you could learn during an MBA course. And it builds the success of the company.

I’m impressed. But I’m not going to follow. There are of course some ideas I’d like to implement but, in both scenarios, model as a whole isn’t copyable. As Tom Evslin writes, a barely-graduated hire won’t be as smart as Bill Gates only when he’s as rude. Typical organization won’t achieve a stunning success only when they spend one day in a week for employees’ pet projects.

I think that organizing a company in a way which allows people to like (just like, nothing more) their employer is tough enough to doom the management to failure in vast majority of cases.

Cutting Costs for Dummies

Cutting costs is a tough job. It’s difficult. It won’t make you many friends among coworkers. And it begs you to throw the baby out with the bathwater. When the company announces a new policy, which sucks, but at least will bring them some money they need, it’s most likely an e-mail addressed to everyone saying something like that:


Hello headcount,

This is our new cost-cutting idea, which sucks. Really sucks. The policy is effective since yesterday. Obey the policy!

Kind regards,
Yours Truly Cost Cutting Department


Yes, that’s the worst possible way of doing that. And somehow that’s also the most popular one. This is wrong on so many levels.

• You don’t give managers a chance to prepare people in a human way to incoming unpleasant change. Sure, in a big organization there are probably a bunch of directors who don’t care. Maybe the whole rest would appreciate when given the chance to avoid ruining their teams’ morale? Nah, they don’t care about that.

• You don’t explain people why it’s done. People don’t like to be treated as mindless golems. I’m not quite sure why, but it seems they just don’t. Maybe that’s the need of feeling important? Who knows?

• You don’t limit information to interested ones only. You spread the doom all over the place. Let them talk about that. Let it be the news of the month. Maybe that will affect their productivity but you can’t be sure.

• You don’t point exactly who is the subject of the policy. All the managers trying to explain their people that the e-mail is a bit too general and someone must have made a mistake accidentally will be grateful. In other case they would have to actually manage their teams, which is so boring. I guess.

You can take that all a bit further if you want. You can announce the cost-cutting idea to those who won’t be affected. Later you can explain them it was an accident and there’s no problem – they don’t need to change anything. You lower morale and productivity and gain no savings. Congratulations. Test passed.

Web Applications Flaws

I believe that the future of software is the web. If you read me regularly, you probably aren’t surprised here. However it’s still hard to imagine the world without desktop applications yet. Why? Although network access isn’t on the availability level of power access (everywhere and always) it’s already acceptable for software except mission-critical applications. The main issue is different. The main issue is usability.

Web applications are still much less usable then their desktop brothers. I’m not talking about functionality, which can easily be enhanced, but about the way the user interacts with the software. There’s list of flaws web applications experience.

• Speed. The Mythical Google Speed, which is by the way still unreachable in rich web applications, doesn’t stun when compared to typical desktop software. On desktop all simple things, like menus to take the first example, work instantly. And I haven’t heard about anyone being impressed by that.

• Contexts. Take the web app. Use the right-click, The God of Context Menus. It will open the context of either browser or Flash Player. Definitely not the context of application.

• Keyboard. Web sites are designed to work with a mouse or a stylus, not a keyboard. On the other hand people are designed to work faster with the keyboard. Web applications very often lack things like shortcuts, which allow better interaction when you’re an experienced user. By the way, there’s another trap here – should Ctrl+F open the application’s search engine or rather the one from browser? When to override browser’s shortcuts and when to leave them in charge?

• Graphical design. I think that’s another great invention of web world. People prefer nice applications over ugly ones. Yes, new, cool, Web 2.0 applications are much nicer than we saw several years ago. However, they all fade when compared to new, cool, Desktop 2.0 programs. Last week I could play with several pieces of software developed with use of WPF and now I’m twisted – Google Reader isn’t so cute any more.

A couple of things can be corrected with current technologies. Microsoft Outlook Web Access has great context menus for example. And, if I’m correct, it’s since 2003. It doesn’t automatically make it a great web application however. Still, people choose the web version only when they have no other choice or in areas where desktop Outlook really sucks (with poor network connection it takes ages for Outlook to stat synchronization with Exchange server).

Yes, we choose (and will choose) more and more of web applications, but in terms of functionality and usability they’re usually worse. Somehow we can lower our expectation, only because the software is installed somewhere else, not on our PC. That’s the subject to play with for psychologists I guess.

Details Do Matter

I’m just after a small conference we organized for our customers. This time preparing whole thing was a bit trickier than usual, as we’re currently in the middle of re-branding process. We needed new pens, new notebooks, new business cards etc. Basically new everything. Several weeks ago we were forced by our marketing to choose design for every darn thingy you can imagine. Of course everything decorated with our new logo, which by the way we had to choose too.

It was a bit of a pain in the ass, but yesterday, when I saw all those conference trinkets waiting for people in the conference room they all looked professionally. Sure, no one will judge the conference basing only on quality of notebook and pen he got, but they’re on the list of things which can change attendees’ impression a bit. The series of them can change opinions considerably. Even when you have a great presenter but an air condition doesn’t work well, there’s not enough coffee during breaks, a reception desk is hidden somewhere in a corridor, constant noise distracts audience, presentations are too long and host plays her role poorly, the conference won’t be a stunning success.

Details matter. Details can change good performance into great one, but they can also change outstanding event into barely fair one. I think this time our balance of details were significantly positive. Our marketing team has definitely deserved some praise here. They’ve upgraded performance from a good to a very good level.

Future of Software

I came across summary of Hasso Plattner’s presentation about innovation. His main point is that SaaS is the future of software (no surprise here) and he references often to Google. Google SaaS success. Google speed. Google minimalistic form. Google this. Google that.

While I agree with many of Hasso Plattner’s arguments, I think he flatten the case of Google. Sure, Google speed came into software development dictionary, but it’s a feature of the search engine, not every Google application. Sure, pure design works perfectly, but another time – for search engine. GMail, Google Reader or Google Analytics have rich, webish 2.0 design.

Google is a flagship example of SaaS success, but depending on product there are different priorities in design or innovation. Pure form and speed of Google search isn’t copied in many of other applications. And you can’t treat search engine or AdSense (which is similar case) as typical SaaS applications. Much better examples here will be Reader or Google Docs which are designed to be richer, nicer and (of course) slower.

Although I'm a big fan of on-line software, I think there's still a significant big gap in usability between desktop applications and their web brothers and sisters. I'm yet to see web application which will be fast, functional and full of features. That's the SaaS future, because it will allow smooth migration of users from desktops to web terminals. In other words, I'm pretty sure that we won’t be ruled by minimal design as the price paid for on-line speed. Web 1.0 to Web 2.0 path shows that people want nice and functional UI.

Teaching Project Management Basics

After a conference we were sitting in the pub pouring beer. As the company was quite big and contained mostly developers, our subjects quickly went into area of a software lifecycle. I was talking with a couple of guys with a year or two of professional experience and barely had gone out of the university. They were working in quite a big team developing an enterprise-level solution. I was a bit surprised with several project/program management decisions made in their team, which sounded like asking for failure. No one had objected.

Sure, there definitely was a problem with project management in their team, but lack of protests was a food for thought for me. After a while I came to question.

“Hey, has anyone taught you project management at the university?”

I couldn’t believe. I know the project management is quite a wide and complex field, but in software development world it’s so common that at least teaching basics should be obvious.

Wait, wait, wait. The question was wrong. I played I-am-the-guru guy but was it fair? Should I criticize their university? I corrected the question.

“Hey, has anyone taught me project management at the university?”

Nope. Not at all. I was lucky with my first job, because I landed in quite well-organized team using MSF to organize software development process. I was lucky with my first bosses, who were aware of importance of project management and had decent knowledge about the subject. I was lucky to see my first team (and product) growth and constant improvements in organization. I learnt all the basics of project management because I had good teachers in my first job. My companions landed it a software conglomerate in a team with rather weak leaders and rather poor organization. How could they learn project management?

As I talk with graduates or undergraduates on different occasions I’m still surprised why students of computer science aren’t taught even basics of project management. In vast majority of cases they start the first job with attitude to software development which I call “student’s projects.” Student’s project is the one which is abandoned when it (almost) works in a couple of scenarios. It’s abandoned exactly a moment after a grade is granted. When you’re lucky it’s 90% complete, what means I would implement it in a production environment only if longed serious trouble. The student’s project usually is much more like a prototype than like a product.

Any software vendor I know expects quite different level of quality. The reason is simple – there aren’t many customers, who are willing to pay money for prototypes. So no matter how their development teams are organized, they need to fill remaining 10% of software development cycle. And that’s exactly the place where basics of project management are essentials.

That’s why I believe universities harm their students focusing on development skills, design and architectures only and leaving areas like project management untouched. Even now when hackers get a lot of buzz and money, they are usually the ones who don’t focus on hacking only, but are also able to finish their products.

Before I’m trodden into the ground with opinions about great universities all over the world which doesn’t suit to above picture I explain: I graduated mere single university, and I had contact with students and graduates from another few (almost) all from Poland. My thoughts are based mostly on opinions about them, although commonness of described issues brought me to fearless generalization on the subject.

Characters Clash

I’m still in climate of (late) performance reviews and, as a simple consequence, I think a lot about my team. In one of side thread of this thinking a question appeared. Imagine you have a well-integrated team. Almost. One of team members is a specialist making his job well, but unfortunately his character doesn’t suit to the rest of the team. What to do with him?

Is it possible to adjust his character? Or should we build around the guy some procedures which will formalize his contacts with the rest of the team? That’s definitely not the case of the primaballerina, in that situation decision would be much, much easier. Just conflict of characters. However, it has already inflicted some damage in people’s attitude to each other.

What would you do?

Screwing Performance Review

Month after the end of the quarter is usually time of performance reviews. It’s often quite stressful and difficult for people to attend those meetings. But they’re difficult for managers too. As confrontation is inevitable stress comes in, especially before those reviews which are expected to be tough. However there are managers who use several techniques which make performance reviews easier. At least for them. Here are top 5 of them if you’d like to follow.

1. Don’t make reviews. Don’t make them at all. It’s a waste of time anyway. Have you ever seen a review meeting which motivated an employee? Imagine how much important work you could do during all this time.

2. Don’t prepare yourself. Oh, if you really have to make those darn meetings at least don’t waste the time to prepare yourself. Sure, you could go and justify every single opinion you state but, be honest, what for? At the end of the day it will be your opinion which counts, not your subordinate’s.

3. Don’t change your mind. Never. You know, when you agree with your subordinate that you should change the result of his review it shows that you’re weak. You don’t want to be seen weak, right? Don’t let someone trick you. It’s you who have better reasons, but you just um... forgot them at the moment.

4. Talk. A lot. Your opinion matters. You are the one who evaluate someone's performance. You’ve written that darn review. It’s all about you. Don’t believe anyone who says something different.

5. Don’t ask. It isn’t important how she sees her career or what he wants to do during next quarter. Their problems are theirs, not yours. They lack perspective so their ideas of improvements won’t be good either. When someone answers even if not asked, don’t listen. It’s nothing interesting anyway.

Although I wouldn’t like to be in your people’s shoes if you chose to follow that path it would definitely make the meetings easier.

I think there’s no easy way here. No one said the management is an easy job.

How to Choose Bad Strategy

I guess you won’t find many questions like above around. Although sometimes I think those strategy-creators up there would use some of these. Not so long ago I wrote how bad strategy labels had chosen trying to kill internet radio stations. It wasn’t much later when I saw this appeal on Pandora:


Today RIAA won another skirmish. Pandora welcomed me with the message:

“We are deeply, deeply sorry to say that due to licensing constraints, we can no longer allow access to Pandora for most listeners located outside of the U.S. We will continue to work diligently to realize the vision of a truly global Pandora, but for the time being we are required to restrict its use. We are very sad to have to do this, but there is no other alternative.”

Congratulations guys, I guess you’re much closer to Pandora’s death. The problem is you don’t see that your strategy is just a lengthening of your agony. Instead of supporting ideas, which would allow you to exploit new possibilities, you try to kill them. You’ve already killed Napster's first life but, be honest, had it changed anything? Kazaa, BitTorrent, eMule and whatever-is-the-coolest-p2p-now came instead. You could have been a part of the new business, but you rejected transition. You stay in your castle waiting for flood which is coming fast. Instead you could have had a nice ship by now. Now you dismiss another chance. What a strategy! I’m impressed. Really.

I prophesy death of labels and incarnation of Pandora-like services soon. By the way last.fm still streams the music to Poland. Another enemy to hit? Nevertheless, if someone wants to follow the way of labels and RIAA I have several advices.

• Don’t look forward. If something works now it will forever.

• Look back. Analyze your past strategies. There are true pearls. Don’t listen to moaners, world hasn’t changed so much to reject ideas which were successful in seventies.

• Don’t look for partners. Especially small ones. Especially new ones. Your only possible partners are companies like yours. Hey, they understand you perfectly.

• New ideas are bad. They always endanger your business. They’re never a chance.

• Stay. If you make bucks it does mean you’re in good place and moving somewhere else wouldn’t be wise.

• Don’t accept what you don’t understand. It would be even better to kill it. Leaving it alive is unnecessary risk. The law is probably on your side... yet.

• Pretend there is no Internet. Hey, people lived without the web 20 years ago so they can live without it now. I guess.

Sometimes when I look at companies’ strategies I think many of those rules are followed. When I look at labels they are all compliant. I take a pity on people like Tim Westergren who have to pay for labels’ politics.

Start Small, Grow When You Can Afford It

Recently I had a discussion with my friend about building own business. As he’s very ambitious he described the vision of quite an established company with a couple of dozens employees as his goal for a first couple of years. Nice vision, indeed. My advice was: “Start small, and then grow whenever there’s a good environment around you. If there is any. Two people on the beginning are enough. You’ll go big later, when you can afford it.”

It’s easy to have big plans, fight on many arenas and then run out of gas. It’s much easier to work on vision and strategy than to solve all small everyday issues or keep cash flow above water level. It’s easy to forget about all costs of growth or overestimate chances of getting a contract. Hiring a bunch of new people in marketing department won’t help when your developers can’t finish current projects. Adding a million bucks in an income forecast by increasing success chances isn’t a self fulfilling prophecy. It just doesn’t work like that (as far as I know).

We forget how much can cost us living beyond our means. Even when we lose just a lousy 100$ per month. No matter if you’re big or small, spending more than you earn and waiting for a hero on a white horse with a big bag of VC money isn’t the best business strategy I’ve heard of. Alas, quite a popular one nowadays.

Solving Problems with Bug Trackers

Ian Landsman with his quick idea about bug tracking triggered a little discussion about the subject. Why we have a problem with tons of bugs/feature stored in bug trackers? Why ideas like throwing out a bug tracker appears? Why we’re advised to leave feature requests tracking at all?

I think the problem lies not within bad, bad bug trackers which become bins storing everything. I think the problem lays in the way we use bug trackers. If your bugs database is cluttered it’s most likely not the fault of application itself.

Why bug trackers become cluttered?

• Organization. You need versions, application modules, priorities, submission states etc. You need people responsible for every bug or feature request. Although it looks fairly easy from the perspective of a single bug, it’s much tougher when you look at all that mess after 2 years for 3 applications (4 versions and 6 modules each) with staff rotation and strategic reorganization introduced by the board because it’s more than a year since the last one. The rules should be clear for everyone. When there are too many submissions with “critical” priority it’s either people overusing it or you have a problem with your product, not the bug tracker. When single person has more bugs that he can grasp it means that they’re either poorly organized or you have a problem with your product, not the bug tracker. When you submit issues only for the sake of submitting them not planning to do anything with them it’s either problem with people’s responsibility or (you won’t guess) you have a problem with your product.

• Cleaning. The bigger the issues database is the more you need to clean it once in a while. Review feature requests which are attributed to future versions in case they’re already done or become obsolete. Yes, it is an additional effort, but you don’t leave cleaning your house only because it’s additional effort. If you do, you shouldn’t at least moan that the house is a bit messy. Another thing here is moving things you know you won’t do in the very version to future ones as soon as you can. Leaving them on developers’ dashboards won’t help you much anyway. Adjusting original priorities is also the part of the work here.

I think that well-organized suitable bug tracker isn’t an option. It’s a must-have. And of course a suitable bug tracker can mean different application depending on a product, team etc. For one of my projects free version of simple 16bugs works well. On the other hand I know teams that use fully-blown Visual Studio Team System installation, including issues tracking of course. One of the best tracking applications I’ve seen was developed in-house – I wouldn’t recommend using it in any other company but for that organization it was like a tailor-made glove. It suited perfectly. On the different hand it would probably look and work lousy. And it would have brought another load of mess.

I’m far from blaming applications for problems with bug tracking. I’m even further from redevelopment of a way we manage bugs and feature request. I prefer to start with doing it right in the old-fashioned way, like a grandma taught us.