A Journey into Softlandia

Dear readers (all of you that still keep that dusty feed in your aggregator),

As much as I liked blogging here, I must admit that I don't have the resources to do it anymore. This does not mean that I will not write anymore! Blogging has been an important tool for improving my writing and my ability to express myself in general.

I have started a blog at my company's corporate blogs site some time ago. First I thought I could write on different topics here and there. My corporate blog is tech oriented, and I wanted to keep this blog more "meta". I wanted to post details of my journey on mastering the software production craft. It turns out that I cannot do both things. I will merge the blogs and everything will appear on telerik's site.

Please update your feed URLs to http://blogs.telerik.com/blogs/twisted_asp_net/atom.aspx

When you get your first comment spam. I am leaving it there for sentimental reasons. All others shall be deleted on sight.

What type of software are you doing? Is it rocket science or the plain "store that in the DB and show it to me later" type of software? Should you hire the best person available or hire two or three mediocre ones instead?

Joel Spolsky's latest installment is about programmer skill. He shows convincing data that programmer productivity varies greatly. You have to be extra careful to get a person that does the job quickly with really good quality. Taking the published data into account, the best programmers might do things ten or more times faster than the mediocre ones. So there is no such thing as "those two are programmers and equal to that one code master". One person might be very productive and besides he/she will not suffer from the communication overhead that two or more people have to bear. I have seen it happen -- small teams of talented people can and will do wonders.

Another important point in Joel's article is that mediocre people do not make it in the exciting and challenging projects. You need skilled craftsmen to build a wonderful piece of software, and an army of drones will not help you do that at all. From another point of view -- no matter how hard you want to be a part of an exciting project, it will not happen if you do not work on your skills first.

Does that work the other way too? Can two bad programmers hurt the project? Is this as likely as to warrant a "no hire" decision if you are looking for new people, but you just can't find the right ones?

The moral for me is to never stop learning new things. Not just new technology, I mean new practices and approaches that will keep the current projects exciting, and guarantee that I will make it in the future, more exciting ones.

I am sorry for the prolonged quiet period. This blog needs some refocusing and reorganizing, so expect some changes really soon!

I think it is time that I admit this in public. I really hate the "best practice" buzzword. Maybe I am a very suspicious person, but whenever I hear those two words mentioned by someone, I start looking for the thing the person would eventually try to sell me. People abuse that catchy phrase -- I see it in all types of argumentum ad verecundiam. "Do this, just because that big company is doing it with wild success." Ahh, the horror.

The timing could not be any better. I just finished reading Cem Kaner, James Bach, and Bret Pettichord's excellent book Lessons Learned in Software Testing. It presents the context-driven school of software testing. The authors make a good argument that there is no universal silver bullet or best practice -- everything is different according to the context. Today I saw a really good argument against that ugly phrase on James Bach's blog. The entry even compares the "best practice" advice to medical malpractice -- prescribing drugs before even examining the patient. I like the analogy.

William Caputo provides a good alternative. Don't brag with silver bullets and universal solutions. Software development is a people oriented process, so the emphasis should fall on Best People. Those that are really good will find the best practice for the current context.

P.S. Lessons Learned... is a wonderful book. It contains not only testing and testing management advice. It is full of people related problems and solutions. It tackles some inherently human problems that are not seen in software testing only. Its 293 lessons will provide you with great insight. Read them slowly, pause after each lesson, and count the "AHA" moments.

This post by Clarke Ching gives some psychological insight on people and their getting the job done.  He mentions that usually people that worry about the quality of their job, and are afraid that they might not make things good enough usually do just fine.  On the contrary -- much self confidence in a person about his abilities is an alarm bell that something might go wrong.

My experience has been the same.  I have seen humble people that get to the job and do it.  And of course I have seen primadonnas that always design the best piece of software, program better than anyone else, and somehow always deliver late with quality problems.

Humility is one of the most important qualities a programmer (or maybe even any person) might have.  I need to remind myself about that more often.

I saw this post about the two critical project success factors on Glen Alleman's blog.  It lists the two critical success factors:

• Have the right people on your team
• Manage the interfaces and progress through face to face communication

I already believe the first part, and I had a gut feeling about the second one.  I have always been suspicious to automated reporting and progress tracking systems.  Now I know it's not just my aversion to Gantt charts.

What was the last time that you got an email from a manager or coworker that you would rather have discussed with him/her in person?  What is the best approach to deal with this and make it happen less often?  I guess two simple rules are in order: never do it yourself, and walk over to meet the person when someone else does it to you.

I saw "fatal apathy" being mentioned on the XP list.  It was defined as a paralyzing situation that follows a bad decision in the past.  We can't do anything now because of this and that bad thing we already did.  Say we can't write an automatic test for the current functionality being developed because the old code is too tightly coupled to get any parts of it under test.  The result stifles any further decoupling as we couple the code even more.

The advice given by John Roth is quite good.  Replace the "why" questions with "what".  The reason or the cause for the bad situation is not important.  Let's concentrate on ways to make things better.  "What needs to be done in order to do that?"

Maybe I can try it now.  Our project gets hard to test because it takes too much time to build, any change requires half an hour for a rebuild.  We can:

• try batching changes and doing them in one build.
• try avoiding rebuilds and do in-place repairs.
• try to optimize the process, and maybe exclude some of the components that don't need to be rebuilt.