Archive

Posts Tagged ‘software engineering’

qTrace is released!

December 5th, 2011 2 comments

After quite some time working on it, we finally released qTrace 1.0, the defect reporting tool you want to have ;) .

To find out more and download the trial version, please visit http://www.qasymphony.com.

Junior developers beware, SOLID principles and design patterns are indeed useful for you

February 13th, 2009 Comments off

I have several times disagreed with Jeff. They are just rare occasions though, given the amount of blog posts he wrote and I read (and agreed with). However, given his popularity as a blogger, any misleading advice may be highly destructive to junior software developers who may turn to his blog for advices. This time around, Jeff bashes guidelines, rules, and checklist with SOLID principles being one of the targets.

Now, young developers, before you start throwing away all the books about design patterns, agile, OO principles etc., let me tell you one thing: if Jeff Atwood is a better developer at all today, it’s because he has learned from the rules preached by more knowledgeable people. Don’t believe? Read this. There you go, Jeff Atwood as a fan of Code Complete, a 900-page book full of coding rules, was so much interested in the book that he even named his blog after one of the book’s symbol. He just seems to forget about where he came from when he wrote:

While I do believe every software development team should endeavor to follow the instructions on the paint can, there’s a limit to what you can fit on a paint can. It’s the most basic, most critical information you need to proceed and not make a giant mess of the process. As brief as the instructions on a paint can are, they do represent the upper limit of what most people will realistically read, comprehend, and derive immediate benefit from.

It’s normal for a very experienced developer to rely mostly on his judgment instead of a set of rules and principles to do thing. But it’s just uncool for such an experienced developer to advise the newbies to do the same thing, i.e. they’d better use their judgment first before resorting to the distilled and valuable knowledge taught by others.

…I’ve found less and less use for rules in my career. Not because I’m a self-made genius who plays by my own rules, mind you, but because I value the skills, experience, and judgment of my team far more than any static set of rules… Rules, guidelines, and principles are gems of distilled experience that should be studied and respected. But they’re never a substute for thinking critically about your work.

The thing is people are not born making good judgment. And one of the best ways to sharpen one’s judgment is to learn from the knowledge of those people who have made good judgment. Only after one has practiced these teachings long enough, making a lot of right and wrong decisions based on these teachings, one will for the first time, really understand about them and don’t have to think about them any longer as they have become part of one’s instinct. That should be the thing experienced developers teach junior developers, not this:

The types of developers who could benefit from SOLID a) aren’t thoughtful enough about their work to care and b) won’t read much of anything

Don’t get me wrong, I respect many of Jeff’s opinions, but I think he should feel more responsible for his influence on those developers who are new to the industry and seek for advices from his writings. Obviously no one man is perfect and Jeff, like any other, doesn’t necessarily always have great things to say. But at least he should acknowledge that he’s wrong when he’s wrong.

Appendum 2/14
On the contrary to what I think Jeff Atwood should do in the previous paragraph given the large amount of thoughtful comments from many of his readers, he seems to dig himself deeper into the hole with his follow-up post.

Is it worth separating between the essential and accidental difficulties of software development?

March 31st, 2007 6 comments

Upon reading the chapter about productivity tools in the classic Rapid Development of Steve McConnell, I notice an interesting point Steve made about the role of high-level programming languages in the context of Fred Brooks’ No Silver Bullet. Read more…