What’s Great About In-House Development
Okay, you know me. My day job ranges from web development/design through to project managements, procurements, implementations and all that jazz. I tend not to talk about it because I believe in keeping what I do here separate from what I do there.
But I came across a post from That Standards Guy today, entitled Why It Sucks To Be An In House Programmer, which caused me to bristle immediately.
Okay, in-house development is only part of my job (I think realistically I did about 40 minutes coding last week), but since I started my first job in 1997, I’ve been working for companies/organisations which carry out at least some in-house development since, and I think TSG is spitting out some unfair generalisations.
Number one. You never get to do things the right way. You always have to do things the expedient way.Joel Spolsksy, as quoted by That Standards Guy
That’s not necessarily true. I’ve always found that if you can explain the business benefits of doing something the “right” way, people accept that it’s the right way and they are happy for you to do it that way. If you’re struggling to find business benefits to justify your “right way”, then maybe you need to consider how right your way is after all?
Our programmers were made redundant last year and me and my one remaining colleague have yet to receive any kind of support to plug the skill shortage.That Standards Guy
Ah, bugger. I can understand you feeling a little demoralised there, mate. Regardless of the business reason behind something like this, it’s going to leave the remaining staff feeling a little disenchanted and maybe concerned about their own futures.
That’s the second reason these jobs suck: as soon as your program gets good enough, you have to stop working on it.Joel Spolsksy, as quoted by That Standards Guy
Again, no you don’t. This is how you do it.
- You make sure you’ve got a well defined project management methodology (I use PRINCE2, but you use what suits you)
- You establish the business case (what benefits will this development bring to the users?)
- You plan your development project.
- What do you need?
- How long will it take?
- What are the users’ needs?
- What are the users’ business processes (can these be refined, too?)
- Do you have clearly defined success criteria?
- Have you written system specifications?
- You get developer(s) to write it
- You unit test it.
- Throughout the life-cycle, you monitor it, — get other developers to look at it and suggest improvements; check it conforms to in-house standards and so on
- You refine it as a result of this review process
- You pass it for quality checking
- You hand it over for user acceptance testing measured against the initially defined criteria.
- You sign it off
And then, once it’s been signed off, you do stop working on it (at least unless a change request comes in). But that’s not a bodge job. That’s doing it properly. You do that, the users stand a good chance of getting a high-quality system delivered.
However it sounds to me that maybe That Standards Guy is working in an environment where maybe better planning would help:
I deliver professional, minimal and clean design with consistent CSS treatment of typography and vertical rhythm and semantic, accessible markup but a website takes more than two days to put together because design is not all about the code either.That Standards Guy
The problem is maybe one of unrealistic expectations?
I’m not trying to make light of the predicament that That Standards Guy finds himself in: it sounds like he’s not exactly working in the most fun working environment at the moment. I’m just trying to say that in-house development environments don’t all work like that.
Maybe I’m just lucky that I work in a proactive environment which plans things and manages projects properly. But I couldn’t imagine doing it any other way…
Hello. I am 
Have to agree. As you mention, problems are nearly always more to do with project management and communication. If you’re in an organisation with these problems - and think this isn’t your problem then go buy a decent project management tome.
I also think Joel has a business reason to paint a rosy picture of development in a software company (namely, his). Their are a whole host of other problems that only come up in that sort of organisation.
Main conclusion? Work for a good organisation with good people. Easier said than done though!
Aww, shucks! Jack’s written about a post of mine
You’re missing a couple of my quotes though:
Not directly quotable but the bit about how I used to work in an environment like yours with all the Prince2 / quality management in place. Those were the days. Even with the severe financial constraints the company was under.
@Gareth: agree with your conclusion
I could explain further my situation but dirty laundry being what it is I’ll sign off now.
And now a quick response to “what’s great about in-house development” (hey, you didn’t really answer that):
- You know your customers - you are one too.
- You know their business.
- You going to be using what you develop.
A bit like 37-signals without the flip-flops (probably).