Fog Creek Software
Discussion Board




In-House Customers Have Different Needs?

I used to work for a software company. I now work for an in-house development team for a large corporation.

Our team scores one, at most, on the Joel Test.

When I make suggestions about better practice - say, having a change control system, or introducing testing - I'm often heard with interest, but at least as often, I hear "Yeah, that might be the way they work in a software company, but this is a business environment."

What could the thinking be?

Do they suppose that the many businesses that were our customers at the software company, had different needs from the business that is our customer in-house?

Do they suppose that software companies don't really have customers to worry about, but are more like universities, following ivory-tower processes for their own satisfaction? Whereas *this* business has a pragmatic, real-world view of customer needs that my last company did not have?

The more I hear this, the more I think it *really* means "In-house development is not supposed to be very good."

Otherwise, why would you try to produce software by intentionally *not* doing things that are done by companies that successfully produce software? Why would you say that their example is exactly the one we should *not* follow?

Does anyone else have any thoughts on this?

Fernanda Stickpot
Thursday, April 03, 2003

I explained the benefits of unit testing and having the tests to validate that future changes don't break anything to a client not long ago. The client developes their own software which they sell to their customers.

"Yeah, that would probably be nice in a new project, but not here. We're nearly done."

This nearly done project needs serious performance tuning on the file export. The export could easily use 50 million function calls to complete. Too much cut'n paste, nearly no reuse and global data.

A nice suite of unit tests would be very practical and money saving.

So no, not only in-house customers thing they have different needs.

Thomas Eyde
Thursday, April 03, 2003

This mirrors my experiences almost exactly. In a previous life, I worked in a high-tech silicon design shop but switched to database programming to secure a job in the vicinity of my wife. Now, I thought I'd brought some useful outside experience into my new job but the status quo just refuses to be defeated. I, too, ran my own Joel test and felt that our methodology could use some extra practices (most notably, source control and unit testing); in three years of campaigning, I've fould *zero* people willing to add the weight of their opinion to my arguments.

Three years is a long time in IT and things have moved on. Our company was sold to another, who then promptly outsourced the IT dept to a "big two" global services provider. Our new masters are keen to impose a One True Process onto everything we produce, one element of which is a Test Plan. Quicker than you could say "cargo cult", our more senior developers (who were "promoted" to project analysts) have decided what those test plans should consist of. Those same people who, for the last umpteen years couldn't see the value in unit tests and haven't written one between them in their life, are telling me that my "comments" on the process are "very interesting" but ultimately irrelevant because the decisions have already been made.

Despite many examples of deployment snafus, there's still no recognition of the need for source control -- even CVS isn't available because nobody has permission to download and install it.

It's a completely different workplace to the one I joined not long ago. The day is filled with frustrations which are too tedious to go into here. I've come to realise that, over time, the neophytes have become the masters. But, instead of moving on like their masters before them, they've simply moved into project management. So, not only are the rest of us left dealing with the shitty code they've left behind, but we're also powerless to initiate any force for change. Meanwhile, these newly minted managers are intercepting and interpreting the mandates from central office and reforming them in their own image.

We haven't had a raise in two years (well, a 1% increase 14 months ago counts, I s'pose) and have just been told that we've had our salary review and that we won't be getting a raise this year. But we should thank the lord that we still have jobs and can look forward to another review in 15 months time. Meanwhile, our glorious ex-leader has just trousered $35 million in a severance settlement.

Getting back on topic, I've often wondered whether I could social-engineer our clients to demand more from us, such as consistent UIs and bug-free behaviour. Sadly, they'd be charged so much that they'd rather stick with the crap they've got. After all, the people who have to pay for the work aren't the ones who have to use the product, right?

Do I sound negative? I guess I'm just too stupid to dump this gift horse and get a real job.

Outsourcing for Dummies
Thursday, April 03, 2003

The answer to your subject line question is -- more often than not in-house corporate customers do have different needs.

After reading your post, it appears to me that the question you really seem to be asking is, "Are all corporate in-house IT departments as f*cked up as the place I am working at?"

If this truly is the question you are asking here then my answer is -- I think so.

Many large corporations have layed off a large portion of their technical staff and replaced them with contractors and consulting firm employees. Typically, the only company employees you will find walking the hallways are IT people who have jobs at the project manager level or above. IMO, most of these individuals are nothing more than clueless suits who are only interested in climbing the corporate ladder and will do whatever it takes to earn a promotion or salary bonus.

The current trend inside these type of corporate IT departments is to reduce IT costs wherever possible. This typically means canning any technical worker or firm who won't work cheap. In this type of work environment, it is almost impossible to introduce productivity changes and expect them to get implemented. IMO, you should forget about trying to make productivity suggestions and concentrate on making "cost reduction" suggestions. Unfortunately, trying to make yourself into a more productive laborer will get you nowhere. Butt kissing (i.e. making your boss look good) is what gets rewarded in this type of work environment.

One Programmer's Opinion
Thursday, April 03, 2003

People generally resist change, particularly big changes.  This is not stupidity; it's often a very good thing, especially when it comes out as, "Our process works reasonably well.  Why change it?"

However, this is a problem when a process is broken but nobody is willing to change.

Joel has some excellent advice on this, in "Getting Things Done When You're Only a Grunt" ( http://www.joelonsoftware.com/articles/fog0000000332.html ):

"A lot can be done to improve the project just by one person doing it. Don't have a daily build server? Make one. Set your own machine up with a scheduled job to make builds at night and send out email results. Does it take too many steps to make the build? Write the makefile. Nobody does usability tests? Do your own hallway usability tests on the mailroom folks with a piece of paper or a VB prototype."

"Many of the Joel Test strategies can be implemented by a single person on an uncooperative team. Some of them, if done well, will spread to the rest of the team."

So, you could just implement these processes yourself, as best you can.

Brent P. Newhall
Thursday, April 03, 2003

To answer the question -- Yes!  Joel describes it best in his article here: http://www.joelonsoftware.com/articles/FiveWorlds.html

...but even with agile methodologies (for example, XP) source control, requirements, testing and bug tracking are important.  Some of these items are elevated to focal points for the process.  The Joel Test should be applied regardless of the environment.

My suggestion is to lead by example.  It is amazing what can become part of a process (i.e. source control, automated testing) because someone just does it.  At my company we have an automated build with unit test that runs every time something is checked into CVS.  Neither CVS nor unit test could be found when I started a little over two years ago.  Initially it ran on a Linux machine that was scavenged after layoffs.  Now CVS is the company standard and many of the projects have unit test.

Jonathan Hager
Thursday, April 03, 2003

Make sure you REALLY like the job before untaking such an effort. It will be a labor of love for a long time, and you might at times feel frustrated when you're not having a large enough impact, fast enough.

Brad (dotnetguy.techieswithcats.com)
Thursday, April 03, 2003

Are there really places out there that try to write software without _any_ version control and can't be convinced otherwise?

Wow. Scary thought.

Andrew Reid
Thursday, April 03, 2003

Fernanda Stickpot:

I think that this thread is partially mislabeled. It's not just about the differing needs of in-house customers. The original post begs the question - why do so many shops wallow in stupidity and abject dumb@$$ed mediocrity?

>> Our team scores one, at most, on the Joel Test.
>> When I make suggestions about better practice - say, having a change control system, or introducing testing - I'm often heard with interest, but at least as often, I hear "Yeah, that might be the way they work in a software company, but this is a business environment."

First of all, don't blame the specific argument being given - that your suggestions are being labeled as irrelevant because the management is "business" oriented. WTF does this mean? As compared to what? A software product business is started in order to lose money and be a philanthropic agency? While other forms of business need to turn a profit? I take that as kind of insulting to say the least.

That "business" label is common but can be interchanged with other argumentation devices that are used mainly to discredit anyone who suggests doing correct or workmanlike things.

The point is - that "business" argument was a cheap shot being used to discredit your initiative by implicitly labeling your intentions one or more of the following: "irrelevant", "too hard", "too expensive", "good for really smart developers at product companies but way too much for humble numnuts like us who only write in-house applications that nobody looks at anyway".

Oh, and don't forget the ever present "but we can't use bla blah because we need to be FLEXIBLE and your suggestions will unfairly rein us in!" That's the common lament of people protesting source code control.

>>What could the thinking be?


The thinking is exactly this: you apparently work with turkeys who enjoy or at least expect no process, no configuration control, and other hallmarks of the crummy hack shop staffed by amateurs and wanna-bes.


Here are two key bits of info on political motivations: working without proper tools or methods benefits the type of employee that *likes* crisis mode management and who revels in being indispensable.  Or, another top contender is the intention to have lowered expectations of the in house development staff.  I'd bet good money that one of these (or both) is the agenda of the people you're dealing with. Simply put, they like "sucking".


Bottom line - you're working with butt covering t*rds. OH, I'm sorry, did I say that? Yes.  And I'm not sorry. Tell 'em Bored Bystander thinks so. Maybe that will shame them. :-)

Bored Bystander
Thursday, April 03, 2003

"Are there really places out there that try to write software without _any_ version control and can't be convinced otherwise?"

Oh yes.

Lets see, a quick count up... yes... more than HALF the places I've either worked for or contracted at have either no version control or something so "in the way" that it ends up being more of a handicap than a use.

PC software houses are the worst I've come across; every project is regarded as a one off, engineered from scratch, almost all of them are "loss-leaders" that don't lead and none of them /start out/ complicated enough to need revision control.

It's only later that that comes home to roost. And Oh My God, does that come home to roost.

It only usually shows up after they re-sold it, slightly modified each time, to a couple of dozen new people.. and then things go to hell VERY quickly.

The current place has a guide to working on software for newcomers which actually says "check code out, work on code, check code and executables in, tell resourcing you're done on that work". Six months often seperates check-out and check-in. The reason for this is that a check-out can take a couple of hours and a check-in can take anything up to a couple of days fiddling before it succeeds.

Duncan's worked for embedded software places where "getting the version of the source code the client has running" has involved trips to attics to get dusty cardboard boxes packed full of unlabelled floppy disks... I guess the lesson from that is that no-matter how crap a job is, it could always be worse.

An important thing to remember about the software industry is that EVERY client, in-house or not, thinks they're "special" in some way[1]. This is why financial places will only hire people with financial skills to write trivial C++ stuff, because they think what they do is special in some way. Games companies really think they need to hire maths PhDs to do games physics and every damn council in the entire of the UK has had their council tax accounts package custom written. Every client uses the "we're special" argument as a reason to do insane things like not use version control, not test software or not buy an off-the-shelf package.


[1] They almost never are. There are times when it is the case, but these are not that large. A friend once wrote, in essence, "grep" for an employer. They did however want to search practically every major book written in English to help them compile dictionaries so it needed to be "a bit faster". I, on the other hand, have wasted a lot of my life re-writing things already better written (like general ledger systems) because the client absolutely MUST have it written in Access/VB instead of just going to PC world and buying a copy of Pegasus Accounts or something. It's not that I begrudge the vaster sums of money they paid to me to have me do it, I just feel my life is being a little wasted.

Katie Lucas
Friday, April 04, 2003


There can be good reasons, such as business competition, for a customer not to select an off the shelf package.  Hopefully this would be an application that supports the core business and not some support service such as HR, payroll, accounting.

Source control is a necessary process in my opinion, as long as there is no misunderstanding for its purpose.  As an example of a misunderstanding... one company bought a source control package because it was advertised to enable concurrent development of multiple projects - the management assumed that "enabled" meant "totally automated"  and proceeded to have projects stepping all over themselves.

Joe AA
Friday, April 04, 2003

Regarding source code control:  It can seem that operating without source code control is like high-flying without a net.  But if a group is making frequent backups, it can operate without SCC.  Developers just learns to make their own peronsal backups occasionally and try to work such that they don't have to go back to previous versions.

I wouldn't want to work that way, and SCC certainly makes our lives easier and provides other advantages.  But it is possible to work without it.

Brent P. Newhall
Friday, April 04, 2003

Of course, its also possible to work without all these new fangled "languages" too -- real men code in hex!

Steven C.
Friday, April 04, 2003

"I wouldn't want to work that way, and SCC certainly makes our lives easier and provides other advantages.  But it is possible to work without it."

It's not about whether it is possible, it is about the gross inefficiency and risk to quality that comes with a lack of version control.  They may as well have been using dollar bills to provide fuel for their fireplace.  The dollars will surely burn.

T. Norman
Friday, April 04, 2003

*  Recent Topics

*  Fog Creek Home