… is that developers are often get paid to write code and not to push the product out of the door…

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…

I had to review few tens of CV lately. A very interesting pattern emerged when we looked at the CVs that were taken to next level – preliminary interviews.

Almost all selected CVs were well written, had little to no spelling errors (a very cheap improvement actually, why everybody isn’t using it?), 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 your favorite programming language.

When somebody is writing a CV I hope he wants to say something. And we’re ready to listen to everyone who can describe in clean and short manner his achievements, explain clearly his goals, expose himself efficiently and may be entertain us with a story. In this case, there is a big chance that he will be able to write (for example) the code to export an hierarchical data structure in few output formats using Visitor pattern.

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

Have just read another definition of what is software quality on Jeremy D. Miller’s blog:

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…

… was to choose Microsoft’s implementation if Ribbon to use in our current development. Yes, I knew it was released as beta. But I hoped to have frequent enough releases from MS to keep up with user’s feedback & fixing bugs. It was my error.

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…

Heard today, from devs working on an old & big project:

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.

From 37signals’s blog, There’s always time to launch your dream:

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

The 37signals quoted:

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.

…say that something of these are not true?

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