The Hardest Part of Coding

What is the hardest part about programming? I've heard many suggestions by peers, bosses, employees, students and professors. I've heard algorithms, front end (html/javascript), backend (database connections, classes), code analysis, and reading/decifering other peoples code just to name a few.

While I would agree that all these things can have their hard parts, I don't believe that any of those are really the hardest things to do. Yes, javascript is awkward, especially if you are used to strongly typed objects. Absolutely java can be off if you are used to loosly type (or not even typed at all) code. Algorithms can be confusing, especially when you start nesting loops. Understanding somebody elses code can be VERY difficult at times. These things still don't make me think that any of them are the hardest part of our job.

So what do I think the hardest part of coding is? I don't think it's the coding at all! I think the hardest part is decifering requirements sent down from business, especially if business is new to the game or in general doesn't know how web programming works. Depending on your management structure this may or may not be an issue, but over the years that I've been coding I think this is the most prevelant problem in coding today.

Maybe you are lucky and most of your requirements actually make sense. If that's the case then I would say the next hardest thing for most programmers would be attention to detail. In my experiance, programmers tend to gloss over requirements, see the general look and feel, and dive in. I know I've been guilty of this, and I know others have been as well. The problem isn't really that we do a once over and start setting up a skeleton and maybe some basic obvious actions. The issues arise when we stop looking at the requirements because we "see how it's supposed to go". I would say seven out of ten times I have to take a portlet or action back to the programmer that did it and show him/her four or five things that were missed. These things tend to not be big, and they also tend to not lend themselves to a story title. Here is an example:

A login flow story is presented to the programmer. It gives the programmer a few criteria for login/logout actions like when somebody logs in, they must stay on their current page. When somebody logs out the should be left on the current page in guest mode. If they logout on a secure screen it should give them a login screen. If they login, it should take them back to the secure page they were on.

This makes sense, and feels like a login/logout flow. The issue is that the requirements weren't closely read, and the checkbox for "Remember Me" that was supposed to be added at the same time was missed. It was also missed that there must now be a forgot password and create account link. I really believe this was missed because of the word "flow" in the story title. Adding those items doesn't really feel like flow to me, it seems like a login action requirement. I hear flow, and I think okay, you are already logged in... now what? Or, you are logging out, where should you go?

So the question that I would present is: Who's fault is it that this was missed? Obviously the issue lies on the coders shoulders as the coder was given the document. The problems with this is the coder was given a 5 page document and one paragraph in the middle added the new login links. Once again, I'm not relieving the coder of blame, but I do believe that the writer of the specs could have broken that up into two stories. Sometimes we get requirements where you can actually see the train of thought that went into a meeting. Business is talking about login flow and perhaps in our sandbox environment playing with it. They are talking about what happens once you login and logout, and somebody in the back of the room has a brainstorm... "Let's add forgot password, remember me, and create account on this portlet!" Cheers are heard throughout the building as this person is praised for their wisdom, and they just write down that requirement right then and there. Clearly it is a good idea, but nobody stood up and said "Hey, maybe this is out of scope for this story?". As programmers or tech leads we can't be in every business meeting and still have any time to code, so we can't police these things and fix it right then and there. Once we recieve that requirement it's like an afterthough, an idea shoved in between two more seperate ideas. Idea A and C are highly coupled, idea B snuck in like a green beret and is hiding between the lines.

I think the solution here falls on the tech lead. We all know that PMs and SMEs (Subject Matter Experts) don't have to code the ideas they come up with. They can mix whatever they want into their cauldren of requirements and just toss it over the preverbial wall for the coders. The tech lead needs to thoroughly read the requirements before they ever even get to the coders and try to rip out the stuff that doesn't fit. I say this as the current tech lead, and this is what I'm going to try to start doing from now on. I know all the other leads are sneering at this right now, because frankly that's crap work. It's not fun, nobody really wants to do it, but somebody has to. I would rather my team of coders spent 100% of their time coding instead of parsing through requirements and coming to me or the PM and asking if we can rip requirements out of this or that and move them somewhere else. Having the tech lead to this also moves blame off of the devs and to the lead. Once again, I realize that kindof sucks, but there is a reason he is tech lead and they are programmers.... he is okay at leadership, he usually has some sort of people skills, and he can take more hits from the upper management. That is a generalization, but I honestly believe it to be true in more cases than not.

There is a large side benefit to this strategy. If the TL goes through all the reqs line by line before the planning meetins where things are assigned, he could answer most questions that the devs might have without having to ask business. If he doesn't understand something himself, he should have asked business before the meeting... this has the plus of getting things fixed before a dev spends two days coding a zip code lookup when it turns out that we really need the full address. Clearly not everything can be caught, and things will slip through the cracks, but I'm pretty confident that this would lower the go-back rate to about three in ten.

There is also a downside to this strategy; however, in that this effectively kills the tech leads ability to code for about a week before the meeting. This also doesn't catch last minute changes done by business (I know, I know, they would never do that). It is for this reason alone that I love using a wiki or Confluence (Altassian) to hold requirements. I can read a requirement and then set a watch on the page. If that page changes I will get an email immediately about it, thus I will at least know something has changed, and at best I will have the time to go over the changes and make sure that they didn't add "Create living kittens from the HP Inkjet" to the requirements page. That's a shoutout to Penny Arcade for those that didn't catch it.

[James Min]

i agree, it's interpreting the req's and agreeing on them.