Fog Creek Software
Discussion Board




So what do we inhouse programmers do?

Lets help Joel out here.  I'm an inhouse programmer, and this is what I do...

1)  Patch up code that was written in the 80s.  Eventually, when the code finally dies we get to rewrite it from scratch.

2)  Somebody in acconts will write a spreadsheet in Excel and use it for quotes.  Then he'll leave.  When it stops working, we have to try and fix it.  Sometimes we have to convert it into a proper app.

Since this takes us weeks, and the original guy threw it together in his spare time, he is considered to be a far superior programmer.

3)  Add desktop frount ends to mainframe apps.  This used to be done in VB.  Now we use ASP.

Ged Byrne
Thursday, February 14, 2002

Slashdot First!

Just kidding!!!

1. Hmm ... what kind of code? I'm guessing some kind of proprietary db? How does the code die? Can you write a small middleware layer stub that'll let you perform a partial rewrite/refactor? How much of the app do you rewrite from scratch?

2. Complain about how not disseminating such information is a indicative of risky behavior and against the corporate goals. This is just corporate level ignorance. Why don't you write a spreadsheet in your spare time and then leave? ;-P

3. Nothing wrong with wrapping a stable code base! (I'm assuming it's stable and it's not the code you're referring to in #1)

Ok, I'm not being terribly helpful here - could you elaborate on specifics (without compromising your job)?

James Wann
Thursday, February 14, 2002

Unfortunately the problem is all down to the way that IT is funded.  Development projects are funded separately until they are accepted.  They then disappear into the production, which has one not so big pot of money for maintenance. 

Not enough money to fix anything properly, but when something breaks we have to get it back up and running as quickly and cheaply as possible.

When this finally becomes impossible, the company is desparate enough to pay for a new system.

Everybody acknowledges that something is wrong, but nothing changes.  This may have something to do with the fact that nearly 50% of the staff are managers.

The advice about throwing together a spreadsheet and leaving, I will probably be taking soon.

Ged Byrne
Thursday, February 14, 2002

Your destiny can be in your own hands.

http://www.livejournal.com/talkread.bml?journal=thesliver&itemid=14255

Simon Lucy
Thursday, February 14, 2002

Simon,

I think the ability of the individual is somewhat limited within an unsound company.

In the end, as I have discovered, non of your efforts lead to any financial rewards.

Time to move on.

Ged Byrne
Thursday, February 14, 2002

I extend existing software written by a mix of long-term contractors (who do as they're told), short-term permies (who don't care about the quality of the software because they've had enough of the b.s.)...

I add data mining functionality to apps where the existing db design is so awful you wouldn't believe... and I don't get a canary to warn of explosive gasses.

I have to import data from old DBF files on a daily basis in order to produce reports within a newer system that is inexplicably missing most of the data it needs...

I provide spread-sheet exports for the data so the users can massage it to their liking (because 'your figures are wrong')...

I write new software which is inadequately analysed and specced by those above me (when it is I, going on my job title, who should be doing the analysis)... and when that new software is cancelled 6 months down the line because the business has changed its mind AGAIN, I despair at ever doing anything worthwhile ever again...

But mostly, I just want to leave and sweep roads or flip burgers, anything but continue to be treated as a code monkey while people who were secretaries months ago get promoted to project management and get trained up on UML (after which they still wouldn't know a use case if it bit them in arse, and still fail to produce anything useful in the way of requirements).

DB
Friday, February 15, 2002

Ged: In the end, as I have discovered, non of your efforts lead to any financial rewards.

That can be true, I'm not sure I was thinking about financial rewards so much as self-satisfaction.  The drive to achieve homeostasis.

But yes, sometimes its just not worth the effort anymore and then you're better off being somewhere else.

Simon Lucy
Friday, February 15, 2002

DB,

Amen, Brother.


I sometimes think that you don't understand what it is like to work at a pathologicallyl self destructive company until you've been there.

You know your there when you start to think Scott Adams has rose coloured spectacles.

We all know that Joel is a really clever guy, but do you think he could have made a real difference at Juno?

Simon,

I agree with you that a company can only really be changed from the ground up, but only if the people at the top allow it.  It has to happen at both ends, or not at all.

I do gain a lot of job satisfaction, but it doesn't pay the mortgage.

Ged Byrne
Friday, February 15, 2002

As an inhouse programmer, I take a common database that is poorly designed (thank you Siebel) and create front ends for it using 2 different tools. 

Add the need to get data using from the database that there is no direct access allowed (thank you Siebel again).  Get visibility rules from the Mainframe, and wrap it all in a nice user-friendly web interface, so agents can access it on 36.6 modems.

Andrew Brown
Friday, February 15, 2002

Why is normalising databases so unpopular?  Its a simple process and makes life so much easier, yet so few databases are normalised.

As for indexing ...

Ged Byrne
Saturday, February 16, 2002

I think its some kind of inherent belief that querying across tables is going to be slower than having it already flattened, similarly in indexing simple rules like 'index all columns involved in a relation separately as well as together' seem to be outside of their experience.

Another good reason for using ORM.

Simon Lucy
Sunday, February 17, 2002

Part of the problem may be that there *are* special cases where denormalization makes sense, either due to business rules (column-level security in products that have no concept of such a thing) or for performance reasons. But having been told that in their introduction to databases, too many developers assume "ah, MY data is one of the special cases, I'll set it up the way that makes sense to me" without ever testing the normlized version.

Mike Gunderloy
Sunday, February 17, 2002

Performance, performance, performance. You spend many happy person hours designing the optimal normalised data model for your problem space, with a weather eye to future changes (i.e. you make it flexible enough to cope with reasonable changes in the business) and wear a happy smile. Then you implement an application which uses your beautiful data model and your smile grows. Then someone does a cartesian join on your two biggest tables and causes the whole system to come to a screeching halt. Management panic and force you to denormalise everything 'for performance'. You then end up with an application specific data model that you might as well implement as flat files because there is no way the data can be used anywhere but this application. You then write extract programs to put this data into a reporting database which will have an uncanny resemblance to your original data model. Unfortunately you can only extract to your reporting database twice a day because your server can't take any more load.

Now your users are unhappy for two reasons;

1. They can't get changes made to the application quickly because each one necessitates changing the de-normalised data model.

2. They can't get 'up to date' figures out of their reporting database because it is only updated twice a day.

I think the preceding entry qualifies me as a cynic.

Andy Todd
Tuesday, February 19, 2002

I'd love to see a denormalised database, because this would imply that normalisation had once been carried out.

All I see are tables with 200 and odd fields that get thrown in when needed.  The database is just seen as a persistant Global space.

Still, I don't blame my fellow programmers, becaues most of them were plucked from a mainframe envrionment and thrown onto the desktop.

I think one of the main reasons that inhouse programmnig teams often produce such poor code is that we have so little control over our own destiny.  After being forced onto yet another platform, you just can't be bothered to hit the books again.  You just do what you have to do make it work.

Ged Byrne
Wednesday, February 20, 2002

The culture here has failed very badly in the opposite direction, with management having zero interest in what's actually being done at the code face.

Other coders here are busy adding ShinyStuff (tm) to existing code (such as COM objects and XML) purely because they can. There is no logical need to do it - all it's done is polished a few CVs up and brought zero value to the business. In fact with such a mess of old and new stuff, maintenance for the poor s.o.b's who will follow after us is going to be a real challenge. Yet when I suggested changing our reporting engine for one that was less buggy, better featured and actually *supported by its authors*, the ShinyStuff fans fought against it and we kept the old engine - because it was too much work to change existing reports (i.e. not glamorous enough to be mentioned on a CV. Maybe I should have said it was an XML-based report engine).

It's gotten to the point where I've given up fighting for the simple route. As I'm looking to leave I may as well join the Shiny brigade and get my CV gleaming too. When I was fighting, all I got for caring about this waste of time and effort was a shouting-at from my boss and of course crappy relations with the other coders. Shininess rules. Business sense does not...

Damn I really must get this bitter 'n' twisted module turned off.

DB
Wednesday, February 20, 2002

Normalizing  or Denormalzing?  Depends on the situation at hand.

Normalization is the best approach, but sometimes it is really as simple as the lack of understanding at the data level which approach is to be taken.

Sometimes, it is completely foolish to normalize a set of data, even if one of its' properties are many, if the data retrieval is denormalized after certain joins take place.  It's pointless to argue with those of the normalization mind.  They can’t grasp it.

Excuses I often get are: 

“There would be data redundancy in the table,” to which I reply, “Yeah, and how will the data be accessed primarily?”  Of course, they see my point, but still can’t get it.

“Well, all of the fields except one are the exact same for each child.  We need another table for that field.”  Oh vay! Hooray!  Another database object to maintain, index and relate for an integer value for the normalized mind.

“So what, I would have to look at the first record of the group to know what the value should be?”  It’s all the same except for one field.  Ever heard of a GROUP BY clause?

But again, I digress.  Forever shall live the normalization masterpieces.

SELECT * FROM TABLE A JOIN TABLE B ON A.ID = B.FID JOIN TABLE C ON B.ID = C.ID LEFT OUTER JOIN TABLE D ON D.ID = C.ID LEFT OUTER JOIN …. Z.ID = AA.ID WHERE A.ID = 1

Syntax Error in Line 1…Ambigous column LASTNAME.

*Sigh*

cg
Saturday, March 02, 2002

In house programmers are the ones who generally still have paychecks coming in.  Consultants spewing the latest and greatest tech buzzword have long since been purged.  It's back to basics, folks.  Get with it, or keep talking to the mirror with all your overused buzzwords.  In a recession, Companies need results, not promises.

SSSSS
Tuesday, March 05, 2002

(De)normisation:

My thinking is to start with a fully normalised database at the beginning of a project.

This may lead to poor performance but ignore that.  A fully normalised database is the easiest type to make changes to.

Later in the project, when your confident that your database is finally bedded down you can denormalise it and reap the performance benefits.

You can save this as an activity for a slow week ( in the spirit of the iceberg effect).  If your doing lots of behind the scenes, no obvious results, type work then spend an hour or so tweaknig and denormalising the table.  The user will see the performance increase and be happy that your not wasting you time.

Ged Byrne
Wednesday, March 06, 2002

*  Recent Topics

*  Fog Creek Home