Robert C. Martin, during his keynote at QCon London 2010, tried to figure out why there is so much bad code written. He offers advice on writing good code talking about a bad code example, Boy Scout rule, functions, arguments, craftsmanship, TDD, continuous integration, pairing, small cycles, patterns, engineering, certification, and other elements contributing to qualitative code.

http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code

One of the best TED talks I have seen in a long time. Simon Sinek talks about how companies like Apple can be so successful when compared to their competitors.

The prioritization of Stories is a core practice in the Scrum agile development process. In fact it is probably the single most important responsibility of the Product Owner – making sure the Product Backlog is prioritized properly to maximize business value (a.k.a ROI). However, there is a common anti-pattern that I see regularly in which the Product Owner and the Delivery Team act complicitly to establish a priority order for Stories that are being committed too within a single Sprint. The need to do this comes from a negative place and it has dramatic consequences for the Delivery Team.
Continue reading »

There are three questions you have when you’re hiring a programmer (or anyone, for that matter): Are they smart? Can they get stuff done? Can you work with them?

Aaron Swartz
(http://www.aaronsw.com/weblog/hiring)

There has been a good debate on the Los Angeles Java Users Group mailing list this week about working with recruiters, both from the job seeker side and also from the employer side.

In my career I have worked with recruiters on both sides of the fence and I think the argument boils down to the same issue no matter which side you are on – working with good recruiters is a good idea and working with bad recruiters is a bad idea. Apologies if you were expecting something more earth shattering!

Many recruiting houses are simply glorified keyword matching services and they all function almost identically. If you visit their offices you will find a large room with two large tables, one designated for “Hardware” and one for “Software”. All the folks around the Hardware table are working to fill Hardware related positions and the Software folks are doing the same for Software positions. There will be 4 to 8 folks at each table, each with a computer and a phone permanently strapped to their head. At the end of each table will be a large white board with the “Hot Jobs” listed with the keywords to try and match, plus salary and commission rate (not surprisingly the higher the salary and commission rate, the hotter the job miraculously becomes). The main purpose of the folks at the table is to process the highest number of resumes as is humanly possible (from active job board postings, from their DB of past resumes etc.) and bring the resumes with the best keyword match to the top of the pile, then do a bare bones phone screening interview (ie. does the person actually exist) and then pass the pile of resumes off to the employer. The employer then has to process the resumes all over again, screen out 80% of them because while the keywords are there, there is an obvious problem elsewhere and then interview the other 20% to find out if any are even close. Most of the time you can achieve the same results as an employer by paying the fees to monster.com and doing the search yourself – it might even be quicker.

But as a job seeker you do need to be in contact with recruiters because many positions are never posted widely/publicly (at the request of the employer). In this scenario the employer is engaging the recruiter to get at their pool of contacts that are hopefully pre-screened etc., some of which may not even be in the active job market, but are known to the recruiter. This becomes increasingly true if the position being filled is higher up the corporate ladder (manger, director, VP etc). However, a bad recruiter will waste a lot of your time if you are not careful.

As a manager, these keyword matching recruiters are the bane of my existence and 50% of the reason I never answer my phone at work (the other 50% of the reason is software sales guys, but that is another post). The endless cold calls just trying to present me “a really exceptional candidate” they have found or “just wanting to know” if I have any open positions. These guys are really the sleazy used car salesmen of the IT industry.

As a job seeker it will be pretty obvious if you are working with one of these houses. Firstly if you ever get a phone call in response to a resume you submitted and it sounds like the person on the other end is sitting in a room full of people talking loudly, then they probably are. I have even been asked to hold the line when talking to one of these guys and while I was waiting I could hear another recruiter at the table talking to another candidate on their phone about the exact some position!

One of the other classic traits of these organizations is their incessant need to keep the job seeker and the employer at arms length from each other – the theory being that they need to control the communication stream so as the employer and the job seeker don’t reach their own agreement and the recruiter misses out on a commission. This is a symptom of the fact that the recruiter and the employer are not closely engaged with each other and do not have a strong working relationship. This also just hurts your ability to present the best of yourself to the employer. You are the person who knows your skill set and experience the best, and yet you are letting a recent high school graduate with 2-days in house training represent you. Another tactic is for these houses to take your resume and rebrand it with their logo and add their contact information and remove all of your own contact information. This involves a cut-and-paste from the resume you submitted and invariably ends up in a less than professional looking document. Just wait until one of these guys takes it upon themselves to actually edit the content of your resume “on your behalf” without asking you and you will very quickly realize that these guys are probably hurting rather than helping your job search.

Also, just be a little wary about the employer if they are using these kinds of companies. Its probably not a deal killer for you as the job seeker, but just pay close attention to what else your employer might not be paying close attention too.

But! There are good recruiters too, they are just a little harder to find.

I have worked with good recruiters on both sides of the fence as well. From an employer perspective a good recruiter who knows your industry and knows the local talent pool can be invaluable. They can help you shape the job description and salary of an open position to align it with what is happening in the rest of the industry and so attract the type of candidates you want. They can find candidates that are not in the active job market because they have built up a high quality contact list of candidates they have placed in the past or have met during prior searches etc.

These recruiters are usually smaller shops with a smaller focused recurring client base. Many work on a mix of retainer and actual placement fees, so they are not all about placing as many people as possible, they have an incentive to establish and keep long term relationships with employers by providing exceptional candidates.

From the job seeker side you will have to do your research to find these kinds of good recruiters. They probably won’t be posting hundreds of jobs on monster.com because they simply are not filling that many positions at one time. All of the ones I have dealt with in my job searches have found me, not the other way around. When they call you, the background of their side of the conversation will be quiet, because they are not working in the bull pen, they actually have an office! They will likely want to talk to you for a while and have an actual conversation. They will want to determine if you are an all around good candidate, not just a good keyword match.

If you are presented to an employer by one of these trusted recruiters, you are going to be going into that interview with a lot of credibility already on your side. Plus you already know you are one of just a few folks that are going to be interviewed, because that is what the employer is paying for – to not have to do hundreds of interviews.

So in the end, a good recruiter is someone you want to be in contact with, no matter if you are an employer or a job seeker. A bad recruiter on the other hand can waste a lot of your time and also actually hurt your chances of finding a job or filling your position.

Great document, in slide format, that is purportedly an internal document from Netflix that defines their company culture.

There are a lot of big ideas contained within, and many are not widely accepted as the norm, so no doubt this document will spark a lot of debate. However, debate is a good thing, because at least people are thinking.

Just posted my $0.02 on this topic over at the JavaLobby on DZone.

http://java.dzone.com/news/certification-or-craftsmanship

There are many types of developers who work in the IT industry. When it comes time to hire a new developer it can be tough to figure out which kind of developer you are interviewing. When I do an interview I try to place the candidate in one of 3 categories – hacker, coder or engineer.

The Hacker

How to spot one:

• Has been coding since they were 12, but have no notable credentials (no college degree, no professional certifications etc)
• Believes all problems can be solved with some kind of “script”
• Is unable to answer questions related to emerging industry trends
• Appears uninterested in training opportunities
• Their answers will be 1 or 2 words in length and no matter how much you coax them, they will not expand on them
• Has an unhealthy fascination with the game World of Warcraft, to the point it will probably affect their performance as an employee

When to hire one:
Hiring a hacker is always a gamble for a development role. Often they make better sys admins than actual developers, since they are quite comfortable working all-nighters in dark rooms (as long as there is a supply of energy drinks and pop-tarts). They can also thrive in a QA role where automation of repeating tasks is a key skill (hackers also tend to like to break things).

When not to hire one:
A Hacker can become a rogue and distracting element in your development team. If you are looking for a team member that will have a focus on quality and meeting deadlines, a Hacker is not for you. If you want an employee that will work a regular schedule that doesn’t include them showing up at 11am looking like they have had no sleep, then a Hacker is not for you. These are the kinds of employees that you find out have been running a personal ecommerce site piggybacked on one of your corporate servers for the last 6 months.

The Coder

How to spot one:

• Probably has a degree, but has no professional credentials (no certifications etc.)
• Can answer common programming questions, maybe even understands Object Oriented principles, but probably struggles to answer big picture architecture questions
• Probably cannot answer questions related to emerging industry trends
• Doesn’t have a strong interest in getting training, attending conferences or expanding their skills in general
• You will have to work to get them to expand on their answers beyond 1 or 2 words
• Their references are probably positive
• They like to play World of Warcraft at least a couple of nights a week

When to hire one:
A Coder is usually a good hire if you are simply looking to increase your development bandwidth. They will be able to contribute to a project in terms of pumping out code, but will need a solid design or requirements to follow closely. You will also need to make sure there is an Engineer close by to keep an eye on them.

When not to hire one:
If you are looking for a people leader or a technology leader, a Coder is not for you. Also don’t expect to be able to have a philosophical discussion about the state of the software industry with a Coder.

The Engineer

How to spot one:

• Has a degree, maybe even an advanced degree, but is not a new graduate. To be an Engineer, some real world exposure is needed to shake off the bad stuff they learned in college and develop their own ideas.
• Has a strong opinion about industry trends
• Asks questions about training opportunities and budgets for attending industry conferences
• Can name some tech authors they like or industry luminaries they agree with
• Asks questions about what development processes and tools are used at your company
• May not be able to answer every low level code or syntax question you throw at them (this is not a concern, Engineers are usually thinking at a higher level and know how to quickly find the documentation about the API they want to use if they need to)
• Is reasonably articulate and their answers are usually more than 1 or 2 words in length
• The interview will be much more of a conversation than an interrogation
• Are aware of the game World of Warcraft, but don’t seem to have time to play it because of all of the tech books and journals they are trying to keep up with

When to hire one:
In general, the Engineer is the employee you are looking for. Just like in sports where you have franchise players, a good Engineer or two on your team can make or break a whole company. They are going to push the envelope in terms of the pace of development, introducing new tools, technologies and ideas and also the basic way in which the team operates. If you are working on projects that require novel solutions to be created, you will need an Engineer, as a Coder will not bring this kind of skill to the table. Also if you want to be able to increase the number of tasks you can delegate, the Engineer is for you.

When not to hire one:
Depending on the project you are working on, an Engineer can sometimes be a bit like having a sledgehammer in your hand when all you want to do is tap in a small nail. If you are working on small simple projects, or the work is generally a matter of taking a set of pre-defined requirements and pumping out a solution that requires little thought, then an Engineer may become bored quickly and you will find them moving on soon. Also expect an Engineer to have a solid idea of how things should work to be effective. Do not expect to mold an Engineer – you should be hiring them to help evolve your team, not to persuade them to the way you do things now. Additionally an Engineer will be aware of the going pay rate for someone with their skill set, so do not expect to get them cheap.

Conclusion

Not all developers are created equal. When you have an open requisition for a new developer, be aware of what kind you are truly looking for. If you need an Engineer, but only have the budget for a Coder, you need to take a hard look at what the longer term implications for your team are if you don’t have the Engineer. Once you are in the interview, make sure you have questions set up to help you quickly determine what kind of developer you are talking to. And never forget what an unusual amount of influence the World Of Warcraft will have on your hiring decisions!

What Drives Successful Technology CEOs? An Informal SYS-CON Survey
— What drives a technology CEO or CTO to success in today’s constantly changing technology ecosystem? We look at the question through the lens of the many interviews and articles we have published at SYS-CON.com which deal, sometimes only in passing, with exactly this issue. Executives quoted include Appcelerator CEO Jeff Haynie, Nexaweb Co-Founder & CTO Coach Wei, the founder of Internet.com Alan Meckler, and the Chairman & CEO of Parasoft Dr Adam Kolawa.

If you have a software team in your company, it is (hopefully) stocked with highly trained engineers that are well paid and know what they are doing, or know how to figure out what to do in a timely manner. They offer the best value for money to your company when they are empowered to make technical decisions, after all, if they are not the technical authority in the company, then what are they there for?

It doesn’t make much difference if the company is an ISV or an internal IT department serving internal customers only. At the end of the day, you have a software team serving customers by providing software based solutions to their problems.

The customer’s role is to provide what are normally called “user requirements” or “functional requirements” – in other words they need to tell the software team what it is that they want the software to actually do for them. It stands to reason that the customer is the best person to ask what the software they are asking for should do.

Now, it is very common that the customer struggles to tell the software team what it is they want. Either they really don’t know, or they think they know but turn out to be wrong. Both of these “incomplete requirements” scenarios can be handled using an agile development process so they should not present a big hurdle for a competent team. The basic premise still remains, the customer’s job is to provide functional requirements, no matter if they give them all up front, or piecemeal along the way.

From those requirements, the software team is charged to implement a solution that implements those functional requirements. As I proposed above, a software team designing and implementing software is the highest and best use of their time. So this scenario sounds like the perfect environment for quality software to thrive.

Of course finding a company that fosters this environment can be hard. Often the culprit that violates this nirvana of quality software is the customer that doesn’t quite know where their responsibilities begin and end. You can smell this happening when functional requirements documents contain statements that refer to specific technologies or architectures. For example, a functional requirement that states “The UI will be implemented using technology ‘X‘ because it is the only one that can handle the requirements” should be an immediate alarm bell. It seems benign, but there are many problems that can manifest from a requirement like this.

The obvious first problem is you have a group who are not the technical authority making technical decisions. This is a political, social and morale issue. Technical people like making technical decisions, that’s why they are technical people and not marketing or sales people. If you take away their ability to make technical decisions they are likely to resent it, their buy-in for the project will drop, the morale will drop and the result will be an inherently lower quality output.

Another problem is that you have less qualified people making technical decisions. If your customer is more technically qualified than your software team, you are probably doomed before you begin. If this is the case for you, forget reading the rest of this article and start polishing your resume. A good software team should contain members that are relentlessly exploring new technologies and trends. Without question your software team will have a deeper knowledge of all possible choices and the ramifications of one choice over another.

Software teams contain a lot of knowledge that is not necessarily written down in policies, procedures or architecture documents. This latent knowledge base is the main value of the team. It would be impossible for an outsider to posses most of this knowledge, particularly the knowledge that is specific to this team as opposed to software in general. The reasons behind certain tradeoffs made 2 releases ago can be a critical knowledge point to have.

This latent knowledge is a double edged sword though. I have seen many meetings between customers and engineers where an engineer will discount a suggestion from the customer, and when the customer asks why the engineer struggles to answer even though he has the knowledge. I like to think of it like breathing. You know that breathing is remarkably important, in fact you do it all the time and you really couldn’t imagine doing anything else. And yet if someone asked you how to breathe, it is quite difficult to explain, particularly if you are talking to an alien that doesn’t have lungs and doesn’t understand the basics of human respiration. Well that might be taking it too far, but the point is valuable. Another analogy is a human trying to explain their existence to an ant. Ignoring the obvious communication issue, the conceptual argument offered by the human is completely incomprehensible to the ant because his reality is so different to the human. So basically, trying to explain software development to a layman is often difficult simply because you have no common reference point and no common language to use. If you try, you will often cause more harm than good.

So is there a time when a customer should define technical requirements? The answer is a definite yes, with a closely followed maybe. A customer can have legitimate constraints that need to be observed. Call them “environmental requirements”. For example, needing the software to run in a Windows environment because that is all the customer has on their 2000 desktops, is a reasonable requirement for the customer to have.

A requirement stating that the software must be browser-based because the customer’s IT department doesn’t want to have to install the software on the 2000 desktops also sounds reasonable. But then the question for the software team is, what does “browser-based” really mean? What if the software could be developed using something like Java WebStart (a sort of browser/thick client hybrid), is that going to be acceptable? What if the software is inherently better delivered that way because of the rich UI that is possible? Clearly this second requirement could restrict the choices of the software team to the extent that the quality of the solution may be affected. The key is to get at the true underlying requirement. If the requirement was restated as “The solution should have a zero-install profile to reduce TCO”, then the software team can achieve the requirement and still have their hands untied to find the best technical solution.

Is the opposite true? Can the software team impose functional requirements on the customer? Again the answer is a definite yes with a closely followed maybe. If the development process is one in which the requirements are written up front and development happens later, then input from the software team is very difficult to take into consideration. Don’t forget, the software team is usually the first ones to use the software being constructed as they test their code. They will often find design defects very early on. Being able to provide that feedback to the customer is highly valuable. That value increases exponentially in an agile development environment where that feedback can be acted on quickly. In the end, the functionality needed is the customers decision, and suggestions from the software team may be ignored for very valid business reasons. Software teams simply need to swallow that pill, you can lead a horse to water …

I have talked about the highest and best use of software development team resources, but the opposite is also true for the customer. If the customer manufactures fridges, then the highest and best use of their time is working with fridges. If the customer is the internal marketing team, then the highest and best use of their time is doing marketing things. If that isn’t the best use of their time, then they are on the wrong team.

The quality of the output of a software project is improved when customers and developers are aware of their responsibilities and work within them. The quality is improved exponentially when customers and developers are also given the ability to provide feedback in both directions and when the development process empowers both teams to act on the feedback quickly.