Maxim Fridental

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?..

1. Building a team for a creative task in a situation where one person would do fine.
2. Expecting absence of flames and philosophical discussions for teams who haven’t been working together, on the same kind of tasks, day to day, for more than a year.
3. Critisizing work of the other team members in the way so that it can be taken personally.
4. Not critisizing work of other team members just because of interpersonal relationships.
5. Inability to question decisions of a boss however wrong they subjectively seem to be.
6. Inability to discuss topics with a boss without being overly aggressive just because he has the final say.
7. Involving a decision maker into each and every team-internal communication.
8. As a decision maker, declaring work finished without asking permission of other team members (it is only possible to cancel or prematurely stop the work by decision, not to finish it).
9. Giving feedback to each and every small detail; being always opionated; not providing enough free room for others.
10. Overriding decisions of others / throwing work of others away without an explanation.

And I’m guilty of at least 6 of those…

Yesterday I’ve received the latest issue of ”test”, which is a magazine of Stiftung Warentest, German counterpart of “Customer Reports”. One article was quite shocking: they have tested 3D TV devices. 

Wow, we’re really in the 3D era now. So, now I would expect that 3D glasses will appear in mass usage pretty soon and obtain a cult status. I would also expect appearance of 3D street signs, 3D infographics in airports, 3D company name plates, apparel with 3D pictures, 3D wallpapers, and various 3D printed matters. I’m also looking for 3D live performances on stages.

I can also imagine DRM-enabled glasses because 3D-prepared images cannot be enjoyed without glasses.

For now, enjoy 3D fashion: http://www.fashionadexplorer.com/l-ellus-leather–c-denim-ad-campaign–s-2010fw#_

A prospective customer asked for a feature requiring a technology I’m not very comfortable with. I have just never used this technology before, but because of my extended experience of commercial software development, I still could give a reasonable cost estimate, which was 15000€.

Before this figure was communicated to that customer, a decision has been made to investigate the technology first. This research took around one and a half days, which is roughly 1000€. The result of investigation was that we can safely offer that feature for as low as 9000€. This time it was pure luck for the customer, because this technology had to be investigated anyway due to strategical reasons, so he has benefited from the results of the investigation for free.

But what would have happened if we had asked him to pay for investigation? Then, he would have invested 1000€  and saved 5000€. A 400% rate, not bad! Comparing this rate with high performance funds, the funds suck.

The thing is, he would have never agreed doing such investition. The result of the investigation could have been that the feature had required more than 15000€. In this case, the customer would have not only spent 1000€, but also paid more for the implementation. Because we work with fixed prices, by offering an unknown technology for 15000€ we also take over the risk of over-budget. Thus, without investigation, the expenditures of the customer are limited by 15000€. Gambling with a chance of 400% win, but also a loss possibility of 1000€+X  is too risky for most our customers.

Now, what would have happened if we hadn’t investigate the technology and offered 15000€ to him and he had accepted the offer? We would have spent the first 1000 out of 15000€ for investigation and implemented the feature for 9000€. The resting 5000€ would have been our insurance premium.

The more I learn about software developing business, the more it looks like selling insurances against technical risks and making money out of fear of unknown.

APPL: making money by being evil.
GOOG: making money by not being evil.
MSFT: making money by making platforms to make money.
ADBE: making money by making software to make beauty.
Open Source: not professional software developers.

Alex Zambelli has provided a simple rule of thumb in his Media Processing Workflow slidedeck:

–H.264 decoding is typically more CPU intensive than VC-1 decoding for the same resolution and frame rate
–In Silverlight 3: H.264 decoding requires about 15-25% more CPU time than VC-1 decoding with similar content properties

Good rule of thumb (for now):
–For HD video, use VC-1 to reach largest audience
–For SD video and smaller, use H.264 if quality gains are noticeable

This “(for now)” part is supposedly a hint that SL5 will/should/could feature GPU video acceleration. Now that would be really cool. With cross-platform video playback being one of the biggest (if not the biggest) forces to win Silverlight installation base, I wonder why this feature hasn’t got it into SL4 scope…

Eric Schmidt in his presentation about Microsoft Silerlight Media has demoed a cool smooth streaming quality monitor. At Axinom, we have our own inhouse tool for debugging Silverlight video delivery and playback problems, so I thought why not sharing it too?

In Silverlight4 RC, Microsoft has added a few important new features enabling some interesting scenarios related to PlayReady support.

Continue reading ‘New Features in Silverlight4 PlayReady DRM’ »

My completely unofficial MDBG Accelerator stopped to work due to a domain name change on mdbg.net. Here is a working update:
Add ‘Translate with MDBG’ to IE8

NP: Installing Android development environment

Have just read a hillarious blog post by Eldar Musayev. If you can Russian, go read it.

Here’s a short version, the way I’ve understood it:

Old-skool Capitalism: the manager kicks asses of his workers and tells them what to do.

Economy of Knowledge: the manager is still kicking the asses, but only his workers know what to do.

Now we’re experiencing shift to Economy of Invention: even the workers don’t know what to do. The economy is making money by starting a project and inventing a solution at it goes.

Managers are still kicking asses (what else can they do?)