Archive for 'Rant'
Okay, now that I got the link-bait title out of the way, I am going to rant just a little bit. I imagine that I’m like most of you and I think that some flavor of agile (little a) is really the best way to develop software.
I think that collaborating with the business and getting things in front of them as soon as possible so that you can make changes to it as you go is a very valuable model. I am also very much for the short release cycles that most agile shops prefer.
What I despise, however, is what I call “Agile as Snake Oil”. There are a lot of disreputable companies that are putting the word out there that all you have to do is hire them and they can “sprinkle a little agile” on your project or your company and you will magically get everything you want.
They crow that Agile means that you can not make up your mind on what you want until the last minute because Agile Developers have to do what you say and are bound by the Laws of Agile to always change the software for the client. They want their cake and to eat it, too. They want all of the spec changes and none of the timeline changes or compromises.
Oh, that they would actually read something like Robert C. Martin’s book, Agile Principles, Patterns, and Practices. I’ll tell you what, I think that if people only read the end of the book, where Uncle Bob tells a tale of two cities, a project where the team does a “traditional waterfall approach” and the same project where the team practices an “agile approach”, it would make a world of difference.
As you can imagine, the waterfall approach ends in disaster, with stress and hard feelings abounding. In contrast, people are satisfied – almost happy – with the agile approach. The HUGE takeaway from the agile story, however, is that it was not a 100% win for either side. They did not hit their original deadline with 100% functionality. Features had to be traded in if the timelines could not move. However, the business stakeholders were the ones who went ahead and made that call.
I covered this in my last “Agile” post over a year ago, but I think that it bears repeating. Every agile project should do these steps
- Gather requirements
- Estimate requirements to determine length of project
- Work requirements in iterations
- Gauge velocity in coding requirements against estimate
- Determine whether your velocity requires you to either cut requirements or extend timelines
- Lather, rinse, repeat
Developers always get a bad rap for number 5 and it is always largely based on our lack of skill at number 2. Estimating is something that developers really should improve on, however, the business needs to understand two major things. Number 1, those timeline estimates are based on developers being able to work on the project at “perfect world” capacity – meaning 75-80% of their time. If developers are interrupted with conflicting priorities, original estimates and timelines are null and void.
Second of all, those who live in glass houses should not throw stones. If the original requirements are so ill-planned that they need to be drastically refined or changed, then developers should be able to refine and change estimates, too, since they are basically working on a different project than the one they started with.
There are obviously no perfect people in this world, so that means that there is no perfect system. Any system will invariably break down because of those imperfect people going around and “being human”. That being said, the best way to get to nirvana is to act like the participants in Uncle Bob’s Agile Story and rely on the two C’s, “communication and compromise”.
Compromising is the original agile. Be retro.
After reading this article that I saw on Hacker News some time ago, it really got me thinking. The gist of the post is that “Great Judgement” is the number one trait of a great developer.
There are a lot of developers who only want to do the “latest and greatest” thing. They practice what I like to refer to as RDD, which stands for Resume Driven Development. Every project is just a way to make their resume that much more enviable. It is even a little hard to fault these people at first blush because in the IT industry, if you aren’t pressing your skills forward, you are quickly becoming irrelevant. However, sometimes developers forget that they are being paid to deliver a solution for a client or employer. The client’s needs should always come first.
Are you doing work for a PHP and MySql shop? Could Ruby or Node or Cassandra help them solve their problem? Sure, but their existing code is in PHP, their on-staff developers know PHP, and finding PHP developers to hire is easier than finding a good developer who knows Node or Cassandra. You may very well be doing them a huge disservice by building them a “blazing fast web scale” solution.
That’s where Great Judgement comes in. New technologies may offer benefits, but there are always trade-offs in technology. The first is your own knowledge. If you are very familiar with C# and .Net and don’t know Ruby, but you try to put together a Ruby on Rails solution for a client that isn’t mandating Ruby, you are very likely going to cost them time and money while you deliver more slowly, let alone any mistakes you are sure to make or hard-to-maintain patterns you might leave behind because of your inexperience.
The second trade-off is the number of available developers to maintain and build upon your code. The system may really hum when you write it in Brainf*ck, but you just pretty much made sure that there are maybe 30 people in the world who could help that company maintain or grow it. Larger companies aren’t as susceptible to this as smaller companies because they usually have rigid standards in place, but the “market” for your code – be it the language, the framework, or even your patterns – should be at the forefront of your mind as you plan.
The third trade-off is not to over-engineer. Some developers want to create a highly robust and scalable system with a caching layer, failover clusters, and load balancing for every one of their solutions. They want a pluggable architecture and a side of fries with that. The problem is that they are making a small inventory application for the secretary to maintain her office supply levels for a staff of 9. Sad to say, but a simple Access database that would take an hour of your time to create may be all that they need.
I haven’t thought enough to actually assign Great Judgement as the number ONE trait of a great developer, but I definitely have to agree with the author, Tammer Saleh, on many of his points. If Great Judgement isn’t number one, it is certainly in the team picture. If you use Great Judgement, you are a long way to delivering valuable solutions to your clients and that may improve your resume way more than buzzwords.
“Absent love for your field, you can’t be a genius. You can’t.”- Malcolm Gladwell
Scott Hanselman posted this quote on the Internet last week and it really resonated with me. It is no secret that I work in an industry full of “geniuses” and we were all most likely the smartest kids in our schools and among our relatives. Some of us (full disclosure: I can definitely be guilty here) still like to occasionally hold a somewhat lofty view of ourselves among the ranks of “the geniuses”.
Mr. Gladwell has written some very good books about ideas, intuition, and observation. I generally enjoy his writing and here I believe he is right on. I keep coming into contact more and more with developers who are not passionate about what they do. By not being passionate, they are doing their employers and themselves a disservice by not maxing out their genius potential. There are several reasons for this lack of passion – I’d like to focus on two.
The first group to consider may have at one time been passionate developers, but have since burned out. I know for a fact that this is fairly common and have come close to burnout a few times myself. Preventing burnout is a broad topic for perhaps another post, but it is beyond our scope here. I don’t think that I’m breaking new ground to suppose that burnt-out developers aren’t blazing the genius trail.
Our second group is made up of those developers who only do this because they were pressed into service at their jobs or they entered this profession because it pays well. If these people suddenly became wealthy, coding is not how they would spend their time. What that means is they are likely also not spending their free time on this craft.
I’m not claiming that individuals in either group are bad people. They are not. At the same time, however, I believe that individuals who don’t love their field will never attain guru/ninja/genius status. You cannot just put in your 8 hours and expect to be on that “next level”. This goes for lawyers, physicists, and therapists, too. If you aren’t putting in your own time reading journals, blogs, attending seminars, or just “thinking the big thoughts”, you aren’t going to grow.
The bright side is that this love can be cultivated. Much like marital love, you can rekindle your love for your craft. The same principles even apply. A common recommendation in marriage counseling is that you really get to know your spouse. Find out things about who they are and who they’ve become that you didn’t know. Fall in love all over again.
In development, that means finding out different things about programming that you didn’t know before. For instance, if you’ve only ever done middle tier work, learn the UI. If you’ve only programmed application code, learn the database. If you’ve only ever worked the Microsoft stack, give Open Source technologies a try. Make the field new, exciting, and alive again.
Even if you are someone for whom life or finances has guided toward technology, you also have hope. Much like individuals in arranged marriages can “learn to love” or “grow to love” their spouses, you can learn to love your profession. Like the last group, branch out and find a niche you are passionate about. Computer science is a very broad profession. You may find you love writing compilers, embedded systems, device drivers, mobile applications, web, rich media, etc. However, if you only ever log your hours and go home, you’ll never know what is beyond your 9 to 5.
I don’t want to sound preachy, but I truly felt compelled to write when I read that quote. Remember the old adage that when you point one finger, you have the rest of them pointing back at you. I write as much for my current and future self as I do for my readership. While I am “on fire” and “in love” with programming now, the natural ebb and flow of life may take that away from me. When it does, my natural desire to compete and be great are going to remind me of this post and I will have to heed my own advice and find something new that excites me.
I hope you have something that excites you, too.
My company is having a very difficult time finding mid-level developers. Our development team isn’t that large, so the number of junior people we can support isn’t that large. In terms of .Net experience, we have 3 relatively junior developers and myself. I’ve done a fair amount of architect work, senior development / team lead stuff, and been doing .Net for about as long as it has been out. That leaves us with a gaping “talent hole” that could be filled by a mid-level developer or two.
The problem, however, is that every resume we see is someone who is definitely very junior or someone claiming to be an architect (who often techs out at lower mid-level). My boss (and I can’t say I blame him) is against hiring someone who thinks too highly of himself and seems unteachable. A certain amount of ego does come with the territory and everyone is trying to get the best job for the most money possible, but people really need to be honest with themselves.
I’ve done a lot of thinking about this and I think that I’ve come to a conclusion on this problem. The reason that we are having such a hard time finding solid mid-level developers is because they are actually very scarce (in relation to the rest of the populace). Hear me out.
Junior developers are – of course – the most plentiful. Every developer who will ever be anything starts out in this rank. However, I believe that the people who will actually become great in this profession move out of this group rather quickly. In talent level, they are my coveted mid-level developers; by experience, they can easily be overlooked as still junior.
Almost two years ago, Jeff Atwood wrote a post on Coding Horror in which he quoted Bill Gates on this subject. I’ll leave you to read the post, but basically someone asked Bill Gates if accumulating experience made programming easier and he said, “No. I think after the first three or four years, it’s pretty cast in concrete whether you’re a good programmer or not”. He goes on from there, but that hits my point.
People who “get it” and have a lot of experience – the “rock stars” that Joel Spolsky writes about – are hard to find. Spolsky claims that you don’t find them easily at all because they are rarely on the market for any amount of time and in essence “hand pick” their jobs.
People who “get it” and don’t have a lot of experience – probably most likely the people I am looking for – are very hard to find because their resumes hide the fact that they are good and are going to be awesome some day.
People who don’t “get it” can have any number of years of experience and they are still not attractive candidates. In the Columbus, Ohio market (where I’m located) there is a relative shortage of developers, so seemingly everyone can find a job. What I’m speculating is that these individuals end up with 7-8 years of experience and think that they should then be able to land a senior job. In my opinion, however, they fall into the category of “poor developer” and shouldn’t be hired into those positions by any reputable company. What may happen is that some consulting firm will pick them up and bill them out at $150.00 an hour as “experts”, but it is really the consulting company’s system that gets them through projects.
(A quick note: I am not saying that anyone who consults is no good. I’ve met several consultants who are of the utmost quality and deserve every penny they make (often they are independent and actually get to keep much of what they bill). However, I’ve also met quite a few consultants who I’d mark as falling into the broad categorization of this post.)
I don’t know what to do about this problem, actually. If you are a good, solid developer who “gets it” and wants to work with the latest and greatest coming out of Redmond, leave me a comment and if we still have positions open at the time, I will personally make sure that your resume gets looked at and unless it is god-awful, I can pretty much guarantee you a phone tech-screening. From there its all you, hotshot.
Disclaimer: Personally, I prefer to use uniqueidentifier as my primary key data type. It cuts down on improper joins (similar looking values aren’t in every table, ie 1, 2, 3) and is infinitely portable among environments. I think the extra space and overhead is worth it.
We have some reference tables in our database at work. This itself isn’t abnormal, everyone has these. What made these tables special was that the IDENTITY Primary Key for the table started at 0. At first I thought that this was awesome. I know it is a debate for another day, but I love that my arrays, counters, etc start at 0 in C#. I know it may not be necessary anymore or whatever, but it comforts me, okay? 
Things soon changed for the worse when I realized that 0 being a significant data value was a problem. “Why?”, you may ask. Well, when you just generically “new up” an int, what is the default value? That’s right, 0. So, if someone doesn’t set a property when trying to identify some reference value, in a 1-based table (or a GUID one) you will get an error because that isn’t a valid value. However, in a 0-based table, that “forgetfulness” will match right up with a value and go in no questions asked. You can’t validate it, because 0 is perfectly fine to have.
Lesson Learned: Zeroes are fine for arrays and loops, but keep them out of reference tables!
