They don’t have motivation to write good code, finish new feature, think about user’s experience or add one more test  – they don’t need a better product.

They are paid to write code…

Windows Azure platform

Depending on your requirements can be a cost efficient deployment option. Not sure about development side of things. If it’s covering 80% of your requirements nicely, what about 20% cases it’s not covering? Most of MS technologies/frameworks are hardly known as being extensible.

SQL Azure & Azure storage

Will it play nicely with NHibernate? I’ve seen mentions on the net that all NHibernate tests are passing on Azure platform. Would like to see a real app.

“Tables” as a document store are interesting. Is it supporting Map/Reduce?

Silverlight 4

After few releases and years it will be on par with WPF (as of 4.0/2010).

I’m loving choice of platforms: PC, web and mobile.

Windows Phone 7

I’m a Windows Phone 7 developer! C# & XAML everywhere. VS 2010 & known tools/process. Not convinced on new UI concept. Don’t like the strong accent on social networking. During presentation had a temptation to stand up and ask: “can it make a call?”.

Silverlight 4 Advanced

Definitely, in a few years Silverlight will be on par with features with WPF.

Nice presentation, learned few tricks in Blend and VS 2010. Presenter looked and worked like a real developer.

Microsoft Surface & Multi-touch experience

I’ve skipped a session and took a chance to play with Microsoft Surface installed by one of (i think) sponsors in the hall. I’ve started playing with it between sessions and missed completely beginning of new one. Dropped it and played one hour with Surface and a HP branded mono-block with multi-touch screen.

Multi-touch is working great on Surface: few games, Paint, Maps. Few very basic, specific apps with “intuitive" interactions. I’d like to see how it works in a more business/data analysis/LOB app. But I’m rather skeptical. They had some kind of “business” app on the Surface but it doesn’t worked because some physical “tags” where missing.

HPs with multi-touch screens: Windows 7 is not a multi-touch friendly platform. You can create small nice “photo viewer” applications but this will not make a revolution – the platform is mouse+keyboard oriented. You can look at iPhone/iPad, where the platform is built on and for multi-touch. Windows Phone 7 is a multi-touch platform with few pre-defined styles for basic controls & specific navigation features.

Found a bug with multi-touch – you cannot close a window by pressing “X” button when the screen is maximized. Probably a hardware issue.

And I haven’t found how to show a context menu (right mouse click) in Windows 7 using a “touch”. As I said previously, the platform is not touch oriented.

Conclusion: Touch interfaces offer good user experience in specific devices and apps. Very specialized and artificially limited. But for “traditional” apps it’s not a good choice. And don’t forget the whole Web. Keyboard and mouse are here to stay.

Selected CVs were well written, without spelling errors (a very cheap improvement actually, why everybody isn’t using it?), well structured, had clean and consistent formatting.

Programming, like many other human activities, is all about communication: talking within your team, interacting with the clients and the most important – writing down your ideas using a favorite programming language.

When somebody is writing a CV I hope he wants to communicate something. We’re ready to listen to everyone who can shortly describe his achievements, explain clearly his goals, expose himself efficiently and may be entertain us with a story. With a big chance (after hiring) it will be able to write (for example) code to export an hierarchical data structure in few output formats using Visitor pattern.

Yes, peer recommendations are still an important channel to get new blood, but in all cases – “all is starting with a CV”.

defining software quality as the structural qualities of code structure that enable a team to be productive within that codebase for an extended amount of time

Jeremy is writing on how to achieve the quality in: Patterns in Practice: A Retrospective. For those who cares about the quality of the software you’re building you have to go over the series of the articles that Jeremy has written for MSDN Magazine.

If you want to be a better developer you may not have enough time to read ~10 books, watch screen casts, attend presentations or conferences, buy costly tools and courses. The cheapest was is just take a half an hour each day over a week and go read those publications. And think about it…

The thing I liked the most is how “cheap” are usability improvements. Change the caption of the button, remove that cryptic description, move important things higher and hide functions being rarely used.

And test it. Iteratively. It’s agile on it’s better form – pick a user or two and just let them do something useful in your app. Notice errors, fix it.

And test it, again…

The usual feedback from MS on questions and bug reports is:

Thanks for reporting this issue.  This is a known issue and will be addressed in our V1 release.  In the meantime, unfortunately, you’ll only be able to … until we release a fix.

The problem is that the Ribbon was released in October 2008. Since then, nothing like a bug fix release was provided. No known date of the next version to be released. No intermediary releases with bug fixes. Nothing.

We lost significant time working around bugs & bad implementation. It’s completely my fault. I should choose a commercial component to achieve our goals.

Do you want to know my second biggest failure?

Choosing for our project WPF Themes also provided by Microsoft. Why it failed? See above. Bugs that make you spend time fixing weird behaviors instead of providing value for the client.

What I’ll do now with all this crap in our projects? I don’t know yet. But I know for sure, that I’ll never ever use any betas (of developer products) provided by Microsoft in a real development. At the end it costs you too much…

Hey, please open that file at line 11108 and try…

That’s… breathtaking…

To be clear, they are talking about source code file from a project that is in continuous maintenance mode, with new functionality and bug fixes added with regularity.

Definition

Technical debit – obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.

Technical debit by Steve McConnell:

If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., “servicing the debt”) that there is little time left over to add new capabilities to the system.

“I’d love to start a company / become a great programmer / write an awesome blog, but there’s just not enough time in the day!” Bullshit. There’s always enough time, you’re just not spending it right.

Now that’s some tough love, but I’m sick and tired of hearing “no time” as an excuse for why you can’t be great. It really doesn’t take that much time to get started, but it does take wanting it really bad. Most people just doesn’t want it bad enough and protect their ego with the excuse of time.

…

If you want it bad enough, you’ll make the time, regardless of your other obligations. Don’t let yourself off the hook with excuses. It’s too easy and, to be honest, nobody cares on the other side.

It’s entirely your responsibility to make your dreams come through.

Q: Are you glad like I am when things flying in your head are written down nicely by someone else?

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.

— John Gall

Reading this remind me principles of agile software development, “release early, release often” way of Open Source Software world and my own indestructible certainty in the fact that a simple working software released today is much better than a complex and over-engineered beast to-be-released-when-it-is-done.

A software is always a solution. Let’s build first a solution of client’s problem, thereafter we’ll add to application all that crap backed in typical business application, like report designers, integration points with 10 external systems and data export in 100 formats. Do the core. Release it. Then go back and do the rest 80% of application that will be used by less than 20% of customers.

• Business software should be boring.
• Users of the business software can work only with grids and input forms.
• Business software are operated by mechanisms, not by humans.
• Ctrl+N, “319.11″, TAB, “160GB IPod classic”, Enter.
• Trying improve user’s experience with business application is a no way.
• “Hi! Our software doesn’t work for you? Our support service will be very happy to help you with your problems”.

Or may be I’m too new here… It’s like Zen?