Moving "house"

I have relocated this blog to: http://programmerswatercooler.wordpress.com



A few months ago, I decided to take a bit of a break from my career.  A chance to wind down, and recharge the batteries. I've been in the business for over 20 years without a real break. So what has this "sabbatical" taught me?  I've learned that a change isn't as good as a holiday, and a holiday doesn't really mean you get the rest you need. I've also learned that it's really hard to put aside something that you love doing, even if you know it's only for a little while, and my break really reaffirmed for me that being a Software Developer is not my job, it's my calling, and what I wish to continue to do for many years to come.

So during my break, I also took a break from writing in my blogs. I had a chance to stop and smell the blogging roses as it were, and I decided to move all of my blogging efforts over to Wordpress, primarily because I prefer the features and tools, and more importantly the user interface which seems to have a better workflow. I suppose I'll need to update a whole bunch of links out there on the net to avoid them going dead. In the meantime, I'll leave this blog up for a while, just in case the occasional lost surfer finds their way here.

You'll find all of these old articles at the new blog thanks to a nice import feature that I took advantage of.

Thanks for reading, and I hope you'll continue to enjoy my articles at my new location.


http://programmerswatercooler.wordpress.com

Defining Technical Debt. Has everybody been getting it "wrong"?

Technical debt is one of those concepts that has both gained a lot of traction over the last few years, and in some ways been misused as a concept quite heavily. It seems that nearly anything and everything that people don't like about a code base gets lumped into a broad technical debt category, so it's getting harder for people to define with clarity what technical debt actually is as the concept becomes more and more muddied but people's perceptions as to what it is they are looking at when they perceive technical debt. Contributing to this lack of clarity is the need to be able to quantify this debt, and to measure it in a meaningful way. The problem is however, that technical debt isn't like bank loan, where you accrue a fixed amount of debt and you pay it of bit by bit, and I can't help but think that for many, the definition of the word Debt has left many feeling that it is something very specific. For others, the issue is that everything they do incurs a measure of "debt" that negatively impacts on the product, so there is a kind of underlying hysteria that leads some people to believe that they need to measure every little thing about their software development, and that somehow they can see a report that will pinpoint where the problems lie. The reality however is both much more subtle, and perhaps much simpler than many people are leading themselves to believe.

Why is it so hard to both find work, and find good candidates for work?

I came across a webcast the other day of an interview with Peter Cappelli from the University of Pennsylvania's business school, where it was being discussed that it is employers who are to blame for the "skills shortages" that we see happening in many industries, and which in my own personal experience in particular is felt quite strongly in the IT industry.

In his interview, Peter makes some really good points about how the human resources departments in many companies have either shrunk or been made effectively obsolete, essentially removing some of the more traditional checks and balances in the recruitment process. He also mentioned how most companies put very little effort into providing skills and training any more, and how the modern screening processes where aptitude tests and applications asking lots of yes-no answers can result in finding no suitably "qualified" applicants out of a pool numbering in the thousands!! It's these last points that I feel are the most telling, and in particular when the modern day hiring processes that most companies seem to use (referred to as the Silicon Valley model) seem to embrace a zero-training + blind-screening process (a subject I have touched on before).

Why is it that Agile is so misunderstood?

Software development is an often misunderstood game. When you tell a complete non-technical stranger that you are a Software Developer, they will often respond with questions such as: "So you're into computers?", or "So you make games?", or even "Can you help me with my computer problem?". Clearly these people have no idea what software development is, and when you attempt to explain how you do what you do, they nod, and do their best to look impressed, yet you can see that they are thinking things like: "I have no idea what this guy is going on about", or they find a quick way to change the subject. This is all to be expected and barely registers with me any more. I am however quite perplexed to have observed over the last few years just how misunderstood software development is by many of the people who are themselves software developers!

I remember being told during the early 80's by every adult who asked me what I wanted to do as a career that I should get into computers because everybody would have one one day and would need experts to make them do stuff. Clearly those predictions came true, and it appears that I wasn't the only kid to heed the advice of his wiser elders at the time - actually I told everyone that I wanted to do something else so that I could look rebellious when I would decide to change to do all that "geek stuff" later on! The thing is, while there are a lot of software developers out there, not all of them appear to be able to claim to be very good at what they do, even after 10's of years of experience. Yes, that was yet another bold statement for me to make, but I have a good reason for believing this, and I might even have an explanation or two for why this is.

Exciting developments...

It's been nearly two months since my last post and I wanted to mention this because it was completely unintentional on my part. I have in short been extremely busy and distracted over the last few months as several very interesting and exciting developments have occurred in my life and required much of my time.

When is it appropriate to redesign a product?

As is my habit when looking for inspiration for a new blog entry, I recently came across a question on Programmers.SE which seemed at first to be asking one question, but was really about something else. In this case the poster seemed to be asking about trying to understand something about the SCRUM methodology, but was really asking about how to convince his company to abandon development on a failing project, and redesigning the product as a new green field project. Naturally I weighed into the debate with my own lengthy answer about this, but it has since had me thinking about the question of when - if ever - it might be appropriate to actually push for a redesign.

I've now worked with my present employer for 9½ years.  In that time, I have redesigned a flagship product twice. For my previous employer, I worked there for only 1½ years and I convinced the company to redesign their flagship product.  Did I make the right decisions, and were these decisions made for the right reasons?

Why is software development schedule estimation so hard?

As seems to be becoming a bit of a habit with me, I've decided to post an answer (with a few very tiny edits) which I left for a question that I found on the Programmers.SE website, mostly because I feel it's a pretty good answer, but also because it was an interesting enough question that I felt it would be "blog-worthy".

So the question was basically about two things, which was effectively to ask:

    Why is it so hard to provide accurate estimates for a Software Development Schedule, and 

    why isn't this as simple as planning a construction process, such as building a bridge.

Software schedule estimation isn't really very hard at all once you have some experience and can base your best guesses on tasks that appear to be similar to something you have done before. So if (as I'm suggesting) it isn't hard to estimate project schedules, why does it seem so difficult?

Very VERY cool Visual Studio plugin

It's not often that I come across a utility that impresses me so much that it literally blows my mind. Yes people, it's true, that today it happened to me... my mind was totally blown away by an idea so simple and yet so brilliant that it only took about 3 seconds to convince me that it is now the most important piece of my development environment. So much so that I see it as a complete game-changer, and it has me lamenting it's inability to be included in any of the other IDE's that I use.

Defining code as "maintainable" is just plain dumb!

There... I said it... and I've done it again, I've made another big-assed bold statement that I am sure will get flamed in some small corder of the universe.  Thankfully, I'll be too busy with my head somewhere else trying to unlock the mysteries of why people think the way the do about code maintainability.  Which means I'll be writing this blog article and totally oblivious to the little flame war that I expect will erupt and threaten to eventually engulf the entire universe if I don't manage to quell the flame with a good well reasoned commentary!  (Phew!! The universe really dodged a bullet there, let me tell you!!)... Where was I?

So the issue (oh yes, I have SO many) is that I really dislike hearing people say things like:
    "...this is good maintainable code..."

or even worse:
    "...this code is Un-Maintainable!!..."

I happen to be a believer that thanks to the almighty Uncle Bob and others who brought into the light Agile and Refactoring and all that really wonderful stuff, we can maintain ALL code.  Yes, I have found my true coder's calling and decided to preach to the unwashed masses that you who are the unbelieving lost binary souls can also learn that you don't have to throw out your code, just because someone has been spreading such a heathenous word as "Un...Maintainable..." (you may hiss and jeeer every time you hear that word spoken!).

Is “Code Smell” still a useful metaphor, or has misuse of the term subverted its meaning?

I've come across some comments (E.g.: here, here, here, here & here) over the last couple of years that decry the use of the phrase "Code Smell" and I've been wondering what the reasoning is for those who dislike it.  I first encountered this term when I read Martin Fowler's Refactoring book back in 2000, yet it's only in the last year or two that I've heard any complaint about the use of the phrase.

I asked this same question on Programmers.SE recently, and then went on to answer my own question.  I'll admit to a little narcissistic pleasure in having written my own answer. So much so that I thought the topic would make a good blog article! :-P

StackExchange, a success, and a failure.

I made a mention in an earlier post that I've been enjoying the StackExchange website for a while.  One of the things that I've been finding interesting is  how the site's Q/A format has been living up to most of the expectations that its creators had hoped for, and yet at the same time it has in a way been a failure.

Actually I find a lot more interesting about Stack Exchange than simply a view of its successes and failures, but I'm known for making the occasional bold and controversial statement so I'd better try and stick to defending my point of view without getting too far off topic.

Beautiful APIs

I am a big fan of the concept of the API.  I have been ever since I realized in the earlier part of my career that you could actually share code across program "boundaries". One of my pet gripes over the years however, is that often when people think about interfaces, they instantly think about GUIs and the most dumbed-down representations that they can get away with in order to avoid "users" getting themselves into trouble.  Even some of the more hardened API developers out there seem to find it hard to get their heads out of the mindset that a GUI is simply one type of interface, and that there are many more types that require the same attention to detail that a GUI does.

I have seen some really horrible API interfaces over the years, and truth be told I've even created a few horrible APIs of my own.  Still, it hasn't all been a mere fruitless exercise, and years of hiding away in the proverbial 'dark corner' churning out API after API has taught me a thing or two.  In that time, I guess you could say I've developed into a bit of an "API-Connoisseur", or as some of my colleagues might think of me as an "API-Snob".

Odd recruitment practices when hiring software developer

A few years ago, I came across an article that suggested a recruitment practice colloquially referred to as posing the FizzBuzz question, intended to weed out totally inappropriate applicants who clearly didn't have a clue about how to write code.  Personally, I had thought that the idea would cause a minor buzz (pun intended) for a while before it seemed to have finally run its course, and yet I came across a question at http://programmers.stackexchange.com/ that seems to suggest that the FizzBuzz question is still regarded by some as a useful recruitment tool.

I'll admit that I'm very surprised that people actually think that this can really tell them anything at all about an individual's abilities.  I get it that this seems to be a possible way to catch out the new developers who either don't have the talent, or that have crossed over from other specialties with even less talent, but the tone of the original article suggests that it's common to sift through and possibly even interview 100 individual candidates and still need to use this "test".  My question to anyone who has actually used a FizzBuzz-ism would be to ask if they actually know anything about recruiting technical staff at all, and programmers in particular?

Yes, I've actually had experience hiring staff for development roles.  It's an arduous process, and yet one I would never leave to the agencies as you can just as easily do a word-search as the agency can, and save yourself a hefty fee in the process.  The thing is, if you are screening candidates based on keywords, tricks and tests, you'll most likely lose the real diamonds underneath the rest of the chaff.