Michael Kimsal’s weblog

6 Responses to “Client input in the web dev process”

1. Cliff said:
   

   October 29th, 2007 at 9:45 am

   Hi Mike,

   I’ve had very few clients debate the finer points of natural vs artificial primary keys.

   I am that guy. I try not to get in the way too much when a potential religous war could break out (CASCADE Updates? Are you crazy? Just use a surrogate for everything!), but when I see incompetence causing me future headaches, I’ll step in. In fact, that’s pretty much my job. I work in a purchasing department, watchdogging the IO department (differentiated from IT, which is hardware and infrastructure and stuff - IO is more systems analysis and development stuff).

   Way too often where I work, upper management has given a budget to some clown who likes to click on stuff in his browser, and then that clown decides the best way to solve his communication/process/workflow problem is to make a web application. He throws money at a web design department in Romania and makes pretty slides to show at the semi-annual management meetings about cross-departmental synergies and everyone can’t wait to go try the app out.

   Then a year or two later, he gets bored with it, and I inherit a real steamer with abused foreign keys, weak synchronization between centralized data sources (if any), documentation that’s two years out-of-date and a look-and-feel which is either (a) deviating from every other app they’ve done, and therefore bewildering to the end user or (b) indistinguishable from most other apps they’ve done and therefore bewildering to the end user.

   So yeah — there may be fewer of us concerned about the quality of the work underneath the visible layer, but we are out there. And we do appreciate the service providers who not only make the end-product pretty, but also have a clue about the guts of the application.

2. Keith Elder said:
   

   October 29th, 2007 at 11:34 am

   I think the analogy of the Interior Designer really hits home. Especially if you are “designing” someone a web site. The client doesn’t care too much about how hard architecturally it is to build something or pull it off and we as technologist have a hard time relating that, “To add a fireplace here in your home means I have to use a whole lot more concrete, sand, brick, wood, and add extra time to do it.”

   I don’t look at the analogy of fixing the air conditioner, I see it as building someone a house. We have to remember that they, the client are the ones that have to look at our work day in and day out after we leave. I tell painters who come into my home and try to get by with shotty work. “Hey, fix this because I have to stare at it for the next 10 years, you don’t.”

3. mgkimsal said:
   

   October 29th, 2007 at 12:43 pm

   Cliff,

   weak synchronization between centralized data sources (if any),

   sounds like a NADS problem.

   http://fosterburgess.com/kimsal/?p=93

4. Andy Brudtkuhl said:
   

   October 29th, 2007 at 2:38 pm

   Thanks for extending the conversation!

5. mgkimsal said:
   

   October 29th, 2007 at 7:21 pm

   @Andy - no problem!

   @Keith - good points, and I know we’ve talked about this issue before.

   @Cliff - I’ve been that guy who’s made the boneheaded mistakes before, and I’ve also been the guy who’s had to clean up after someone else’s. I think to some degree everyone’s been in both shoes at one point or another. It’s not until you have to clean up after someone else, though, that you can really grow and become a better developer yourself. Fixing your own mistakes is one thing, but seeing the domino effects of years of bad decisions piled on top of one another can really make you think twice before shipping shoddy work.

6. Cliff said:
   

   October 30th, 2007 at 12:46 am

   Re: NADS or not NADS&mash;
   I liked your post (aside: which brother were you discussing that with? Your youngest? Can’t imagine your middle brother has much to do with SQL-vs.-hard-coded PHP), but that’s not what was happening here (though it has come up in our environment before).

   In the specific case I referred to, the app developers recognized that there was a very nice centralized Oracle database in the German HQ containing data they needed. Instead of doing live-lookups (which would have been completely feasible for the production app, but slower for their Romania-based development team), they copied tables on a regular basis into an MSSQL database. Not ideal, but still acceptable.

   Here’s where it gets stoopit. These tables they were copying had only a few columns with well defined primary keys. Something like

   NAME Null? Type
   ——————————- ——— —–
   DIV NOT NULL VARCHAR2(2)
   DESCR VARCHAR2(40)

   where DIV is the PK representing a divsion like “BC” or “MD” and the DESCR is the long-text form of the same thing like “Body & Chassis” or “Motor Drives”. The boneheads were copying the tables, but fusing the DIV and DESCR fields into one field in their MSSQL copy, so that it looked like “BC Body & Chassis” in the app. I am OK with displaying that in the application that way (for select boxes and such), as long as it’s the application layer fusing them together. Alas, no, they did it in the database and therefore any updates to the description of the division (and our divisions tend to rename themselves at least once every two years) resulted in a duplicate division showing up in the app, and of course confusing the end-users, a la

   <select>
   <option>BC Body & Chassis</option>
   <option>BC Body, Chassis & ABS Controllers</option>
   </select>

   I agree with you when you say

   It’s not until you have to clean up after someone else, though, that you can really grow and become a better developer yourself.

   I think part of our problem seems to be that no one is making the screw-uppers also be the clean-uppers.

Leave a Reply

Cleaker 2.1 created by Adam Walker Cleaveland content rss | comments rss

Creative Commons | xhtml | css