Maxim Fridental

I work 8 hours per day. If I’m in a normal mood and health and averagely motivated, I spend only 2 to 6 hours per day developing software, with average of 4 hours per day. The rest time I spend on other activities.

This is an absolutely deliberate decision of mine.

I can only be productive so many hours a day. If I would try to force me and develop software in my unproductive state, I would create more bugs than software. This effect is widely known among software developers and many cool names are assigned to that, for example the Flow that can happen in the Zone, in The Cave.

No matter how you call it, the lenght of the Flow can be trained: the best software developers I’ve even seen could develop software productively 6 - 7 hours a day on average, in a course of several weeks. The worst programmers I’ve ever met could only bring a half an hour once during the whole week.

Experience and training not only raise Flow duration, but also deepens understanding of the process: novice programmers don’t even feel when they are in the Flow and when not. Somewhat experienced developers can tell Flow zone apart of unproductive time, but would force themselves to work outside of the Flow time, sometimes because of a wrong understood discipline or loyalty, and sometimes in a hope to engage the next Flow period. And the most experienced developers would just switch and do something else.

There are plenty things to do. Communicating, documenting, specifying, installing, testing, participating in UI design and in business concept creation, trying out new things or just catching up with the news. Not that those things don’t require to be creative, but they require different brain parts than software development. And most of those things are either expected to be done anyway, or can be done by software developer and would bring additional profit to the company (as opposed to spending unproductive time with surfing on the Facebook or coffee klatching).

By being consequently self-disciplined and replacing software development outside of the Flow zone with these other activities, experienced software developers raise their efficiency (in terms of ROI on their salary).

So that is undoubtfully a Good Thing.

Having agreed on that, two logical consequences of mis-management can be considered.

The first one is that you cannot speed up software development by increasing working time. One can cleary see that increasing working time can only increase the time outside of the Flow, so that less experienced developers would produce additional bugs (but not additional software), and more experienced developers would produce more documentation or tests, but not software. The burn out after a couple of weeks will complete the desaster. The very best outcome of overtime are bugs that look like a usable software in the short-term perspective (so called clickdummies or throw-away code), which might have sense sometimes. Fortunately, most of people know about this effect and generally consider overtime as a “no go”. Many software developer contracts here in Germany prohibit overtime explicitely (you may not regularly work more than 40 hours a week), and that’s good thing too.

Another consequence is not that much known: you cannot speed up software development by freeing up the software developer from some of his non-development activities. Speaking of me as an example, I need 2 to 6 hours per day of a non-development tasks to fill up the time outside of my Flow. If you free me from some of those tasks, it doesn’t mean my Flow time will increase and I would produce software more quickly. No, it would only mean I will have to find out and do some other, may be less important, non-development tasks.

The only really working way to speed up software development is to increase the average Flow time. Speak with your software developer to find out more about how to do that.

Personalization is a concept from the world of web, meaning the ability of the web application to recognize and tell apart different users and act differently on per-user base.

To enable personalization, users almost always have to invest time, and sometimes money, to sign on. In exchange, they can obtain direct services, for example, remembering their filtering and sorting choices and other preferences, their payment and delivery data, or providing them with a unique identity by allowing to use specific nicknames and avatar images. Such services are the reason the user would sign on in the first time.

Besides, some indirect services or improvements can be provided, for example, using user’s first and last name in the communication, or taking the user’s gender into account when rendering the user interface. Such services often include psychological tools with the purpose of influencing user’s emotional state, and are therefore trickier to get right. You have to take the internal logic of the user’s interaction into account to decide how or whether to implement such personalization.

A simple example can be given speaking about personalized greeting. In the beginning of the web, when a cookie has been invented and made login possible, it was a custom to start each and any start page of a personalized web site with a “Greetings, Firstname Lastname, and welcome to this page”. This practice has been abandoned completely with the beginning of Web 2.0, when people started to think more carefully and thoroughly about emotional value of their UI and its influence on the user interactions. The user’s name is still present on home, but not in the greeting form. The single known exception of this rule is Amazon. Interestingly enough, personalized greeting remained intact in newsletters and generally in e-mails, and made it to a true standard — a non-personalized newsletter looks nowadays as an epic fail.

So what’s the difference?

The user mental state for newsletters can be described as “in the middle of something”. If it is an e-mail, the user will be distracted from whatever he was doing by an outlook notification. So when he begins interaction with the newsletter, his attitude is the classifying one. He doesn’t care that much about the contents yet. He wants first to classify. Is this stuff important or not? From the person I like, I hate or I don’t know? Short or long? Does the sender wants something from me, or gives something to me? Depending on the classification, the interaction can end in the very first second with deleting the newsletter and optional adding the sender to the junk mail rule.

Even if it is a paper mail, the similar attitude will apply, because people typically fetch their post on the way home or out of home, so they would want to sort the mails quickly before actual coming home or sitting in the car. In these circumstances, a personalized greeting could help avoiding the unfavorable category of SPAM, because it indicates that the sender at least knows something about the recepient, so that the mail would probably not be completely unrelated.

Later on, during the reading the newsletter, the personalized greeting may even lead the user to believe the e-mail has actually been written by a human, unless the trick effect is destroyed by other wording (like wrong gender in spite of unambiguosly identifiable name).

The user mental model for visiting web sites is different. Here, the interaction is initiated by the user, and he is a returning visitor (otherwise how would we know his name?), so that, most probably he already knows of the value of the web site and classifying the site will not be his highest priority. Often, users visit web sites to get some service, information or products. So their attitude is very similar to one when entering a shop, cinema etc: the most interesting thing people normally focused to are the products, service or information themselves, not the web site providing them. A greeting, especially personalized only with user name without any further advantages for the user, is only distracting customers from their main focus. It might be as counter-productive as “can I help you?” of a seller immediately after customer is entering into the shop, forcing her to move her eyes away from that beautiful shoes in the window that motivated her to enter in the first place. Never stop customers staring at your goods — just be right there when they finally reach for their purse…

If you look at Amazon’s personalized greeting, you’ll see that their layout focuses you into the search bar and the recommended products in the main content area — the products you actually interested in. Me personally, I haven’t even know about existance of the personalized greeting on Amazon before writing this article. It is well hidden in the outer top space. I believe, if they would put it in the middle of the screen, and have you to access products by additional clicking on some link or navigation, their sales would measurably drop.

The moral of this unexpectedly long article is that indirect personalization services require at least the same, or even higher level of user interaction design efforts than direct personalization services. Take that into account and resist placing a personalized greeting to the home page, with the only reason that it is easier to develop than a shopping cart.

 The personal nanoeconomics of a geek begins typically in his childhood, when he gets his hand on his first computer and his parents detect that he is spending more time with computer than other children do.

Other children have several hobbies, the geek has only one. So that while others can typically dance, play guitar or sing, play some kind of sport, and can talk about various far countries they have visited, the geek can only support flame wars about static type-checking.

Other children socialize. So that they later have friends, business network, partners and beloved ones. Geeks are often lonely and eventually learn how to get used with being alone and living without support of friends.

Other children learn how to cook, fix things at home, drive a car, punch into faces of various assholes, etc. Geeks don’t learn these things that much.

Geeks spin and twist their brains during education. Others spend the absolute required minimum of time and efforts in the school and college, so that they have time for making money, more socializing, or just hanging out.

As a result, geeks are good in software development, and others aren’t.

Being a geek is a huge investition. It is hard to valuate absence of private life, but I think we’re talking about millions here. The geek itself might even not realize his investition, thinking that spending life like he does is just a huge fun and right way to do, but it is an investition never the less, and at least when he’ll stop getting fun from software development, he starts to realize it.

This investition pays off, when the geek finds his first job. He doesn’t necesserely earns more money than others, but at least he gets a huge moral reward of being a micro-copy of god in his virtual universe.

So far, the skills and abilities of a newbie geek were continuously increasing.

But rather sooner than later the geek will hit a job not allowing him to develop himself. No matter why. That can be a programming technology rapidly going out of fashion, a need to support a legacy system all the time without the ability to use any of essential software development skills, or just repeatedly unrealistic deadlines not allowing to finish anything.

And then, the geek will realize in what kind of situation he is. While his already huge, and constantly increasing investition still allows him to work as software developer, he cannot stop and make a pause, because the software industry will rapidly devaluate his investition. Geeks have to constantly develop themselves, otherwise they could land in a nightmare and become an idiot both robbed of a private life, jobless, and too old to start making contacts and partnerships.

Geeks are always striving to produce a good, or when possible, the best software, and they are always trying to apply whatever new cool technology that would improve their CV and their standing on the job market. Other people often think that it is because geeks are irresponsible children who only want to play with bytes and ignore the business. Some of them are even going further and believing that geeks either cannot or don’t want to care about the business at all. Well, they might be right. I suppose, 5% of geeks are really childish. And the rest of us can clearly feel the merciless rules of economics on our own skin.

Little can be more harmful for a software development team than team members immediately after a successful previous project.

Continue reading ‘Success is harmful’ »

Two days ago, @ScottGu has announced new features scheduled for Silverlight 5 on the Silverlight Firestarter event. He has said that there were over 21000 votes about the new feature set collected from the Internet, and around 70% of them have been scheduled for SL5.

Now, this is truly amazing.

Just think about it. Which other vendor of a commercial technology with installation base of at least 60% worldwide would allow you to vote for features and then just implement them — for free and within a year? Can you vote for a feature in HTML6? And when you’ll get them, in 2030?

I can’t wait to start using SL5 beta. Here is a list of features I will value most:

Hardware-accelerated video decoding! First, this will HUGELY expand the range of devices able to play video with Silverlight downwards. Netbooks barely capable playing Youtube-quality without glitches will be able to play 720p or even 1080p in their full glory. Second, it can improve playback of some scenes that are challenging for SL4, but not a problem for native players like Windows Media Player or VLC, which will allow HD-Video-philes to enjoy the Silverlight movie experience in premium segment. Third, this can radically prolong battery life of all portable devices playing video.

Typography improvements — Text clarity, Multicolumn layout. The current text rendering is just plain awful. You have to spend substantial time to work out your design inside tight limits, if you need to provide a compelling typography with Silverlight. I hope this will be radically improved in SL5, so that apps will have crisp AND quick text rendering by default, without any tweaking. As far as I understand, there will be also a possibility to convert text into vector graphic (something which has always been available in WPF and has been stripped for unknown reasons from Silverlight). Depending on how it will be implemented, this might also enable many important and interestring scenarios, including placing text along a curve, using perspective, or just surround each letter with a border.

P/Invoke. No details about it, but if it will allow to load and work with WinAPI and .NET Framework libraries, this will be another huge improvement. One of the Silverlight issues is that it is a stripped-down version of .NET. Quite often you need some functionality and it isn’t there. I’ve never understood, why did they develop a parallel .NET instead of re-structuring existing .NET Framework, extend its security model to incorporate strict Silverlight security, port a couple of most important modules to Mac OS X, and implement on-demand framework installation (as soon as first SL app needs some library, it can be downloaded from Azure). So, back to real world. P/Invoke in SL OOB apps will be rather a workaround for this, in my opinion, unbalanced architecture decision, but nevertheless, a very important one opening a huge number of business opportunities.

LOB support improvement. WS-Trust is now supported. It is funny. Two years ago, I was consulting a big international company. They were deciding whether to use WPF or Silverlight OOB in their frontends deployed in many businesses around the world. They wanted to use WS-Trust and were asking me how to do that in Silverlight 3. The answer was “it can be done, but we have to implement the WS-Trust stack ourselves”, which was a Silverlight killer.

I want to mention a couple of other announced things, which I’ve found quite interesting, but I’m not sure how are they related to the real-world Silverlight-based ISV business: Pivot and Crescent. I suppose, they showcase Silverlight features that can be used for innovative LOB apps. If you haven’t seen them, take a look.

One last comment on the Firestarter event: you’ve got to watch the presentation of Dave Ossip (start time: 00:56:11). This is one of the most concise and rational product presentations I’ve ever seen. It is still marketing speak, but more marketing effect is being achieved with less marketing bullshit bingo. Not a big deal, but my geeky soul could consume it without to agonize (I’m looking at you, SAP presentation video).

Now, when WP7-based devices are available, I was thinking about buying one. After all, I can easily develop software like a custom twitter client on WP7 without having to learn anything I don’t already know.

The “only” issue with WP7 is that I have a couple of apps on my HTC Hero, which I absolutely need or at least would like to use  in my daily life and which I don’t want to miss on WP7. Here is the whole list (as of today):

• SCUT gPen — an IME allowing to enter chinese symbols by “painting” them with a finger
• Swype keyboard IME. It is not that really quicker, but the fun using it works like a drug. You don’t want to switch to normal keyboard once you’ve started to swype. It is like eating without salt and pepper.
• A tethering app. I’m using EasyTether but would use just any other possibility to avoid paying crazy sums for hotel WiFi.
• Hanping Chinese Dictionary or an equivalent. At best, the whole info from Yellowbridge should be integrated in the app.
• MapDroid — a map app, which caches parts of the map locally so that you don’t need to pay crazy sums for GPRS roaming on your weekend trip in the neighbour land.
• Barcode scanner with Google and Google Shopping interfaces
• WiFi Analyzer to show surronding WiFi networks graphically, and Antennas, to show surrounding cell base stations graphically
• A simplest MP3 live streaming client of any kind. I enter an Icecast Url, it plays it. Well, I guess I could write this one myself if it isn’t available yet.
• Kayak and Ustream clients, just for fun

So, these are all anchors so far, which don’t allow me to switch to WP7. My feature request for the WP7 Marketplace: I would like to be notified per E-Mail, when the WP7 apps with the same or better feature set  will appear there.

In response to the Mary Jo Foley article about apparent Silverlight strategy shift (I’ve mentioned it), Bob Muglia has now clarified a couple of things. To spare you a visit of his blog, here is my short version*:

a) Microsoft has failed to put Silverlight on to iOS (and, for some unknown reason, on Android).
b) Microsoft has failed to provide a viable OS for an iPad-killer
c) Given the fact how quick Apple and Google develop their market shares in this connected devices area, Microsoft’s knee-jerk reaction was to support at least something to be able to be present on these markets.

This something is happened to be a new version of the Hyper Text Markup Language. Which is very unfortunate due to two reasons.

First, it is still the HTML we all know. Think about “design by commitee”, browser incompatibilities, the need of backward compatibility, and complete lack of understanding the real-life needs and use-cases of software industry clearly shown by its academic creators, first and foremost by Tim Berners-Lee.

Second, it is seen by some (crazy) developers as a serious competitor of Silverlight.

The results of this move are suboptimal. If Microsoft will follow the loud requests of some panicing folks and will feel itself under pressure to release some next Silverlight version, no matter how half-baked it is, it would damage the quality and stability of the Silverlight platform. If they won’t, these folks might crack up and jump off the train.

IMO, the best reaction for all Silverlight developers is to calm down,  write off this year’s PDC and look forward to the next year’s MIX. After all, Microsoft has announced support of HTML5 in IE9 months ago, so these are old news.

Windows Azure is a more interesting PDC10 topic, but I will write about it in the next post.

(*) Okay, not exactly the short version, but my own speculations on the topic. You may want to read the original post.

There is a wave of wondering on Twitter, why Microsoft speaks so little about Silverlight on this year’s PDC conference. Mary Jo Foley even goes so far citing Bob Muglia saying that Silverlight is [only] the development platform for WP7 apps in her provocative article “Microsoft: Our strategy with Silverlight has shifted”.

I’m not sure if Muglia is an authoritative source of information though; judging on his replies on the key talk I’m not sure he was able to fully understand the technology he was speaking about.

I would rather see the HTML5 vs. Silverlight topic as publicly visible part of an iceberg of some very political power struggles inside of different Microsoft teams. You know, that kind of thing nobody in the world really needs besides a couple of hungry narcissistic managers.

Anyway, this has made me to reflect, why am I so vividly hating HTML. And this is the story I’ve came up with.

When I’ve started to learn programming, the relevant articles were printed in electronics magazines, somewhere inbetween of discussions about the most economic way of building an SW antenne and problems of making printed circuit boards at home. At those times, there were only two languages to be used for freaks like me: Assembler and BASIC.

One of my first programs in BASIC has printed a red box and looked like this:

10 LINE (10,10) — (50,10)
20 LINE (50,10) — (50,50)
30 LINE (50,50) — (10,50)
40 LINE (10,50) — (10,10)
50 PAINT (11,11), 4

And it was kind of cool. Ever since that time, I use the red box test as one of the first tests when I start using a new programming language.

Being able to paint a red box on the screen is a quite important step of mastering a language, because, after all, any UI can be seen as more or less complex set of filled polygons. Of course, you wouldn’t always compose the UI from polygons (unless you’re developer of a 3D engine), but, “if nothing else works”, it is nice to know you have a “plan B”.

In Silverlight, the red box test looks like this:

<Rectangle Canvas.Left=“10” Canvas.Top=“10”
Width=“40” Height=“40” Fill=“Red” />

In some aspects, it is arguably worse than the BASIC version. In essence, what Silverlight (together with your GPU) does is translating this XAML into a sequence of operations equivalent to the BASIC snippet above, but you as a developer don’t have possibility to control this sequence. And less control is always worse than more control. Besides, the XAML is a little too wordy and inconsistent: in some cases you use “Fill”, in other cases “Backround”; sometimes you use “Width” and “Height”, in some other times you’re allowed to use “Rect”, and so on. But, all in all, it is quite concise and readable representation of your intent.

Now enter HTML. I’ve never worked with HTML5, but passing the red box test in HTML 4 was a quite non-trivial task. For starters, you don’t have any figures. If you’re lucky enough and your box is really rectangular, you can misuse the DIV element. Well, actually, it is a hack, because it is supposed to be just a container of other elements, not some visual form on the screen. But, hey, who cares.

So, my first try was

<DIV width=“40” height=“40” background=”#FF0000” />

which, of course, has failed. For some unknown reasons, I cannot set those values as direct attributes of DIV. I have to use the CSS language instead. I don’t quite understand, why “id” and “style” and “cssClass” and “name” are all valid direct attributes of DIV and “width” isn’t. But, again, it is HTML. Milliards of folks on this planet have installed a web browser ready and waiting for my HTML app, and that’s a reason good enough to endure any hacks.

So, my second try was

<DIV style=“width: 40px; height: 40px; background-color: #FF0000” />

that has failed again. To make it work, I had to add some content inside of the DIV:

<DIV style=“width: 40px; height: 40px; background-color: #FF0000”>
&nbsp;</DIV>

Strangely enough, now it works even without the &nbsp;, at least on my IE9 Beta. Am I missing something or has the standard changed?…

Now, the next step was moving this box at position (10,10). I’ve added setting of “left” and “top” properties into the style, but this has failed to work again. After the third defeat in a row, I have given up. Eventually, I’ve learned the magick of “position” and different placement models. But it was too late, I have already pronounced my judgement.

HTML is not a language to be used for application development.

You cannot reflect your intent in a concise and readable way when using it. It is kinda nice for making an occasional word bold or italic. Or even place an image with a textflow around it. But developing something like Outlook Web Access with this stuff… No way! You have to be a reckless hero on drugs to be willing doing that.

Now, I’m hearing that HTML5 introduces the concept of canvas. Drawing a red box on this canvas would look like this

var ctx = document.getElementById(‘canvas’).getContext(‘2d’);  
ctx.beginPath();
ctx.fillStyle = “red”;  
ctx.moveTo(10,10);
ctx.lineTo(50,10);
ctx.lineTo(50,50);
ctx.lineTo(10,50);
ctx.lineto(10,10);
ctx.fill();

Welcome back to the BASICs. In 1980-ies, every PC in the world had BASIC and was ready to paint red boxes. Now, in 2010-ies, we will eventually have a HTML5-enabled browser on every PC in the world, and it will be able to paint red boxes.

I wonder, what kind of middle age has happened between 1980 and 2010? Wasn’t by any chance HTML the reason of this regression? And why should I ever trust this four-letter word?..

Is it me, or PDC10 looks very strange? There are only two main topics — the phone and the cloud. There are less sessions than in 2009. And the PDC web site (build by Vertigo, who else) doesn’t even allow to link into session detail pages. I might understand such a limitation if the session chooser (aka the Guide) was build on Silverlight 2, because implementing deep links back then in SL2 required a little bit thinking. But no, the Guide is in HTML / Silverlight 4. Crazy…

Nevertheless, here is a list of sessions I’m interested in:

• Optimizing Performance for Silverlight Windows Phone 7
• Things I Wish I Knew Three Months Ago about Building WP7 Apps
• Creating Custom OData Services
• Build Outstanding User Experiences in Windows Phone 7
• Making Money with the Windows Phone Market Place

It is time to say it aloud: most of software development books are dangerous.

And when I say books, I don’t mean the shameless waste of not renewable resources like ASP.NET in 21 days, Visual Studio for Dummies, and other printouts of help pages, screen shots, tutorials, and code sample listings. No, I mean books like Software Design Patterns by GoF, Object Oriented Analysis and Design by Booch, Extreme Programming series by Kent Beck, and other iconic and deeply philosophical books.

Ever since Brooks’ Mythical Man-Months we software engineers believe in existance of Software Development Crysis, shame ourselves for the poor quality of software we produce, and desperately dream about the silver bullet, this magical and beautiful thing that would finally liberate us from our guilt complex.

Now, here is the silver bullet: we are not guilty. Guys, we overestimate our control over software quality.

Time pressure and unrealistic deadlines are the number one reason to cut on software quality. Therefore, we try and go into unbelievable deeps of smart and sophisticated processes and methodologies to squeeze yet another 5% of efficiency and free up yet another hour we can dedicate to the only activity that can increase software quality — to the thinking.

But being completely honest to ourselves, we cannot deny that having 5% more or 50% less thinking time would not play any significant role to the outcome. To achieve really satisfying results, we need much more thinking time. So much time that some people even believe we would work on software endlessly if we were allowed to. Unfortunately, it is often impossible. There is almost always a deadline, either due to budget constraints, or coming from marketing strategy to use the big wave of some launch event, or even to win over a competition and be first on the market.

There is no such thing as enough time in a software development project. But looking at the bigger picture, I can’t help asking myself: is the software development phase of the project really the bottleneck? The part where the whole software quality gets lost? Because of these poor software developers unable to write a bug-free software in the first try, and with the speed of a typist? Are the activities happening before the development phase also so sophisticatedly optimized and mercilessly streamlined like ours?

And the answer is often no.

I speak about cases, where pre-development activites are paused for two weeks just because some important decision maker acts as a bottleneck due to his busy schedule. A whole two weeks lost! We would implement a couple of additional features, or 50 unit tests, if we had this time!

I speak about cases, where an important information making the planned software architecture to explode comes in too late, just because some team members either incompetent or playing politics.

I speak about cases, where software development is being outsourced, and the customer’s Purchase and Legal spend a month to negotiate terms and conditions with the vendor whom this customer has already been worked with for a year.

I speak about cases, where the project setup includes several vendors that must cooperate but are in competition with each other, so each inquiry would take at least a couple of days and involve quite a lot of politics.

I speak about cases, where software development workgroups are not stable teams of people who have already been worked together and know each other strenghts and weaknesses, and be able to trust each other, but rather being dynamically gathered together from people who coincidentially were free at the project kickoff time. So that the workgroup has to spend days for neccessary philosophical discussions and alignment…

And this is why I think the books are dangerous. They imply that selection of a programming language, coding style, diagram graphical language, choosing exact procedures to exchange information inside the workgroup, the release timeline, and all such stuff, is important. Often, it isn’t very important. They imply that if we do everything right, we can achieve reasonable software quality. Often, it’s not true. And they imply that we are those who is most responsible for software quality. Sometimes, we are the least responsible for it.

Before going into the great lengths and discussing how yet another programming language would make the software better, wouldn’t it be more reasonable to profile the whole software project and eliminate the biggest waste first?..