igloocoder.com

Eagerness to fail

Tue, 25 Oct 2011 11:10:39 GMT

If your developers are eagerly taking blame for failures on your project they’re either:

a) buying into the concept of collective code ownership and have a commitment to quality
or
b) are trying to get blamed for everything so that they can be fired and rid of your place of employ.

Where do you start building skills from?

Thu, 08 Apr 2010 05:00:00 GMT

In the past I’ve had to take development teams and build their skills. It was part of what I was hired to do. “Build an app, and at the same time make our developers better.” I’m back at it again and today I had a chat with someone online about where do you need to start.

First you need to know what your goals are. Usually I find that management is, by asking me to make their developers “better”, looking to increase quality, decrease development time and increase maintainability. All of these are pretty vague and there’s certainly no one day course for each one, let alone all of them. So where do you start then?

One of the first lessons I learned while at basic officer training was that before getting my section/platoon/company working on a task I needed to know what their skills (special or otherwise) were. The lesson was all about resource management. I’m starting a new project complete with a new (to me) development team and once again I’m being asked to make them “better". I could go into a meeting room right now and tell them all how they should be doing TDD, BDD, DDD, SOLID, etc. Some (most I hope) of you will agree that these are practices that can make you a better developer. It would be far more prudent of me to walk into that room and ask instead of state though. I should take the lessons of my Drill Sergeant and initially put effort (and not much will be needed) into evaluating what skills (special or otherwise) the team has. That knowledge is going to set the foundation for how I will approach making these developers “better”.

One of the questions raised in the conversation I was having today was “When we talk about things that we can throw at developers to learn, something like DDD is (sic) beneficial. By the time someone reads the ‘blue book’ they should know quite a bit. Where would you place it (sic) relative to SOLID or the other good practices?” This raised the question of what knowledge in what order when dealing with under trained developers.

For me the whole idea revolves around one thing building on another. Yes you could dive straight into DDD, but wouldn’t it be easier if you understood something about SOLID, or OO Fundamentals? So what is my preferred order then? Depending on what the developers skills are I may start in different places, but usually the order would be something like this.

Tooling. Understanding and being effective inside Visual Studio and other tools that are used every day.
OO Fundamentals. Abstraction, Encapsulation, Polymorphism and Inheritance.
DRY. Simple code reuse techniques.
SRP. Single Responsibility is the foundation (in my mind) for all that follows.
OLID. The rest of SOLID.
Coupling. Why developers should care and how they can deal with it effectively.
Application Layers. How to use logical layering to build more flexible applications
TDD. With the foundation for good design acquired, developers are ready to learn how to apply those design skills.
DDD. How to think about business and translate it into code.
Frameworks. With the foundations built through this list, I feel developers are ready to understand how to use tools such as nHibernate, StructureMap, log4net and others.

I made the mistake that most developers have; jumping straight into frameworks. While it didn’t set my career back, I did need to take a step back and put concerted effort into building my way back up to frameworks again. The best part? With all of the fundamental and foundational knowledge, learning almost any framework is quite simple.

You can’t expect to blast into a room full of developers and expect them to follow this (or any list on this topic) to achieve overnight success. It’s going to take time. Time, effort and commitment. At least the transition from one learning topic to the other will be logical and smooth.

Failure: Napkins and a completed product are not good enough

Thu, 08 Oct 2009 23:57:12 GMT

Continuing on my journey through failures and the lessons that I’ve learned, we’re going to make a stop at a project that I did when I worked at a very small (but successful) development shop.

I started at this shop and one of the first tasks that they assigned me was building a reporting engine for a POS style’d application that they were re-developing. This sounded fine by me as I’d just rolled out of a company where I’d done the exact same thing. I gathered what little info I had on the new and old applications plus the reporting that was being replaced. People dropped print out copies of existing reports on my desk. I was getting my bearings with regards to the outputs that may be needed, but I still was completely lost when it came to what the user experience should be. It wasn’t too long into this project that I realized this (I hadn’t written any code yet in fact) and decided that I needed a sit down with whoever was going to act as the client.

After finding out who I should talk to I set up a meeting so that I could gather some requirement stuff. I sat down and laid on the table that I wasn’t sure what the expected experience should be when we finished this thing. The response was “It should be configurable.” I asked how. I was told “We want to be able to change things like logos and stuff when we put this out to different clients.” Okay…this person was obviously thinking of the final reports. I redirected the conversation back to the user experience leading up to the generation of the reports. The advice I was given at this time was “We need the same selection criteria as we currently have.” Nothing more (nothing less mind you). When I asked about layout, modality (this was a WinForms app) and other things that every user would see and have to deal with I was met with blankness. After an hour of probing and questioning in different ways I left the meeting holding onto one detail…the criteria must be the same as before.

I left the meeting believing that the user experience was firmly in my hands and that anything I did (within reason and practicality) would be acceptable. Oh my was I wrong. I worked for about a month and a half on the product and had some working reports that I could show so I asked for a desk review of what I’d done. None of the user experience was acceptable. It didn’t mimic the green screen style of the system we were replacing. In the eyes of the reviewers, I had horrifically failed.

For some reason, when trying to initially gather requirements I chose to ignore my past experience, which had taught me that just because a client didn’t state something, it doesn’t mean that they didn’t want it. I should have known to dig harder to pull those requirements out. That was a large part of my failure. One simple assumption quickly transitioned into a mistake which grew into failure.

How could I have fixed it? Well, the obvious answer is that I should have asked more questions and taken more time before getting started. Sure, that will work, but I like to get things delivered quickly so having a large up front requirements gathering task, just isn’t my style. The not-so-obvious answer is that I should have started, but delivered after the first week instead of waiting one and half months. I should have mocked up the user experience in a way that conveyed my intentions and direction and shown that too the parties concerned. I could have done it by drawing up some forms and linking them together to show navigation and mock content. I could have take the decidedly lower tech solution and just drawn up some story boards. Either way, after one week I would have known if I was on the right track or not. If not, I would have had a great opportunity to use the existing mockup as a conversation starter to elicit more requirements and then I could have started over.

Having to start over after one week is hardly a failure in my mind. In the case of lacking guidance it would have acted as a necessary step in gathering requirements. Better yet, I only would have burned one weeks effort instead of one and a half months. That is a more responsible use of the company’s money and a much better way to get exactly what the business needs. Fail fast and succeed.

Failure: Interviewing for a position

Tue, 06 Oct 2009 03:05:45 GMT

Experience is simply the name we give our mistakes – Oscar Wilde

Continuing on my series of posts themed around failure, we’re here to look at an interview that I once did. It resulted in me taking the job. That was the failure. Before we get too far into this, let’s step back to the beginning…..

When I was just getting started contracting/consulting independently, I was presented with the opportunity to be a team lead for a project. I was told that the client was very excited to have me as a possible candidate and with my experience. Feeling good about the fact I was desired by a company I went off and did what I thought would be the first in a series of interviews with them for this position. I arrived at my interview and nothing seemed out of place when we got started. There was the obligatory HR person and another who was introduced as the Project Manager. As I’ve found to be the case, HR takes the reins and leads us down a touchy-feely path about how I work with people and “tell me about one time that you were in a stressful situation and how you dealt with it” stuff. As I was expecting that this was simply a starter interview that would determine if HR and the PM thought that I’d fit in their environment and team, I played along for about half an hour. That’s when it got different…and I didn’t notice enough to act on it.

The PM started to investigate my technical skills, or so he said he was going to. He led off with a monologue about the team, the project, the client and the importance of all these things. After about fifteen minutes of me listening to his manager-speak he asked if I thought I could handle this, to which I replied that I could. He immediately followed that by asking “So you know about design patterns?” I was relieved. Finally I was going to be able to show some of the technical skills/knowledge that I’d amassed over the years.

“Yes, I have experience with the theory of them as well as their practical applications.” I left the door open for the PM to take the design pattern conversation where he wanted to which was….

“Okay, I think you’ll be able to work with our library of them then.” Looks at HR person, “I think we’re done here.”

And the interview ended. I was so dumbfounded at that being the technical portion of the interview I couldn’t react and left, my mouth agape.

The next day I was offered a contract that saw me leading (at one point) a team of sixteen developers on a project that nearly had an eight digit budget.

Where is the failure in getting a lucrative, long term contract? I had no idea what I was getting into. Zero idea. I didn’t make sure to ask a single question. Interviews are a two way process. The employer needs to ensure that the interviewee isn’t selling a false bill of goods, will fit the culture, etc. The interviewee has to ensure that the role on offer will fit them, the culture is one they can work in, the project is interesting, etc. Employers get a detailed CV detailing the history of the interviewee. Usually it’s a couple, or more, pages in length. The interviewee gets a boilerplate job posting and Google. The knowledge of each other is firmly slanted in favour of the employer. As a result interviewees have to spend more time probing during the interview to try to level the playing field. I didn’t do that and, as a result, failed myself into a position that was a less than enjoyable experience.

I needed to ask to have a technical person in the interview. I needed to ask why it was rumoured that this project was nearing 100% developer turnover rate in the last twelve months. I needed to know what the codebase looked like. I needed to know what the current developers were bitching about. I needed to know a lot more than I did.

I’ve since learned that I don’t allow an interview to end until I’m satisfied that I have enough information to make a decision. If people claim to have to end the interview due to other commitments, I ask to meet with other members of the project or team. If they won’t produce those members, it counts against them. If they won’t schedule a follow-up (if required), and one that has more than just HR in it, it counts against them again. The process isn’t done until you can make a well informed decision. If you can’t you need to tell the employer that and walk away if they won’t help you to.

Allowing that interview process to get me into a long term contract was a mistake…and an experience. Certainly one that I’ve learned from.

Hiring internally

Sat, 03 Oct 2009 16:49:43 GMT

In our Brownfield Application Development book, and in previous posts on this blog, Kyle and I have talked about the different personalities that you can encounter while working on a development project. Unfortunately many of the types we listed, and that you see and remember, are negative. Because development is such a social task (whether you like it or not) conflicts in personalities, styles and objectives are easily surfaced. Add on a heavy dose of introversion and natural social ineptness and you have a cauldron of simmering conflict just waiting to bubble over.

During the hiring process HR and dev teams do their best to eliminate candidates that are obviously going to bring these types of issues with them. Sometimes it works, occasionally they slip through and you have to deal with them. Unfortunately, it’s very rare to see the same diligence applied to the transfer of people from one internal team to another. The results can be disastrous. About a year ago this happened to my team (I say my because I was the tech lead for the project).

We, as a cohesive and very productive team, were ticking along meeting deadlines, turning out high quality code and generally getting praise from the clients for these things. Management decided that we had more work that we were going to take on and decided to transfer another of the already on-staff developers to our project to assist with the new work load. Don’t start thinking the Mythical Man Month and adding resources to an already late project. We weren’t late. In fact we were ahead of project schedule at that time. On top of that the work being assigned to the new team member was isolated in it’s own branch with a thought of it being included in a future release, not the one we were currently working to finish.

Knowing that this developer would be working in isolation I decided that the impact to the team was minimal and shed any worries I had at the time. Things moved ahead for a few weeks before they came to a crashing halt. I won’t get into details about what happened but the underlying problem was that the developer recently assigned to our team didn’t have the same beliefs or culture as the rest of the team did. The result was a series of very animated and heated conversations that led to a requirement for serious and significant policing of the development actions of this person. In the end the original team had to declare to management (above the project management level) that having this individual working on the project was adding significant risk to the current release and had already jeopardized the following release. The result was that the offending developer was removed from the project and a 100% re-write of his code (four months effort) was required to bring it to the project’s quality standard.

The lesson that I wanted to convey from this incident was that you have to be diligent in the screening of any person joining your team, regardless of if they are an external or internal hire. Blindly accepting a new resource since they are already within the organization doesn’t preclude them from introducing risk and conflict to the project. If you are a team/technical lead, architect or manager for a team, you have a responsibility to protect your team from distractions, morale killers and risks. In this case flags should have been raised months before this individual joined the team, but trained with it. The statement “It doesn’t matter what the client wants, I’ll give them what I think they need” was boldly stated and I failed to remember that when the speaker was pushed onto our team. I failed my team by not filtering based on this past interaction. Don’t let internal recruitment cause you to fail yours.