Web Development

General discussion


web cowboys..(my rant about them)

By Shellbot ·
oh my god...
our wev dev's just put a batch of web application enhancements live this morning..and now that i've gone to look at it, i realise they used an OLD OUTDATED test copy to do the work on, and they then replaced the live version with it.
After speaking with them in my best *you better have a good explanation* voice, i've come to realise that they they are even more incompetant than i thought they were.
Now, everything is working as it should..the problem is minor cosmetic tweaks and label value changes..fixable..
(oh ya..a copy of the pre-update live files is nowhere to be found..as well as previous test folders..seems someone maybe tidied the folders up a bit)

Its just going to be a painstaking process to pick through all the minor changes made in the past few months.
I know..i could get them to sort it..i'm sure there are backups somewhere that we could pull out and mess around with..i'm sure if i called the manager we could get them to spend the next week p1ssing about trying to fix it..
but to be honest, why bother..if you want something done right, do it yourself..so i'm going to do it (i've said so with my boss and she agrees..we can't trust them to fix it immediatly)
We were seriously thinking about kicking these guys to the curb (well, i want to anyways) and i think this has sealed the deal..


This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Consider a Change Management Process

by Wayne M. In reply to web cowboys..(my rant abo ...

Let me gently suggest that, tempting as it may be, fixing the software yourself is acceptance of the current practices. I would prioritize steps in the following manner: have crucial problems fixed immediately, define a development process, resolve all remaining issues using the new process.

"Crucial" is going to be a subjective evaluation, but bear in mind that time and energy spent on resolving these issues is time and energy not spent on defining a workable process. Set the bar pretty high for crucial.

There are several items in this post that lead me to believe that the company has a broken or non-existant development process. I would suggest working at defining or improving the Change Management process, Testing process, and Configuration Management process. I am not a big fan of CMMI, but would recommend looking at some of the agile development approaches such as XP (Extreme Programming) or Scrum.

All changes must be written and approved by someone outside the development team before implementation. This can be as simple as a note on a 3x5 card (XP) or an entry in an Excel spreadsheet (Scrum), or can be a full-blown change tracking system (most CMMI implementations). Each change must be approved by a cognizant user representation, the on-site user (XP), Product Owner (Scrum), or CCB - Change Control Board (CMMI).

A Testing process should also be put in place. This provides both an indication that a specific change has been completed and validation that other parts of the system have not been degraded. For reasons of convenience, these tests should be automated as much as possible, so as to run without manual intervention. When necessary, these may be augmented with manually run test. Note that the acceptance criteria for the manual tests must be explicitly stated and known to the developers prior to the start of implementation.

With the previous two processes in place, Configuration Management becomes a lower priority. Configuration Management becomes a means to keep developers from stepping on each other and a means for handing off software baselines between groups.

With a process established, one can now go back and create or resubmit change requests for changes lost in the latest release. A pattern has now been set to avoid reoccurrence of this problem.

Establishing a process is probably going to meet with better reception than a request to throw the idiots out. Remember, there is no telling what the replacement idiots will do. Go to the boss, say that there is a problem, and here is an approach to prevent the problem from repeating itself.

Collapse -

i hear you

by Shellbot In reply to Consider a Change Managem ...

I've said as much to my superiors myself..but they don't listen much. The company are "nice chaps" and do other work for us in other areas..but they are pretty incompetant. Because 99% of the "superiors" have no clue about IT, they think a handshake and a chat are good enough. They initially thought the product we got was the greatest thing since sliced bread..
i mean, it uses the in-ter-net...wow eh!

To demonstrate how badly this was handled..the (minimal)initial requirements gathering was done (badly)internally , these guys were awarded the project on the basis that they were cheapest, very little documentation was produced, they designed, implemented and tested the application before any technical staff were hired. It was 3 months after my company signed off that they hired me to "look after" the database and help the users learn to use a poorly designed product..

they paying for it now as the basic data model is flawed and its going to require a huge chunk of complete rewrite..

i wouldn't hire these guys to walk my dog..there is no way they are going to get the contract to fix the mess they made.

I pulled some overtime and fixed the overwrites they did. Thankfully I document EVERYTHING and save copies of it everywhere....so all i had to do was pinpoint the areas and copy the changes in.

Note: We don't even have a maintenance contract yet (application has been live for almost 18 months)..my company feels that its easy enough to deal with them, so why bother..
mental isn't it..i could quit on the basis that i work for idiots, but to be honest, its a good job, i'm regarded as a intellectual goddess and its pays pretty well..

Collapse -

That is

by rob mekel In reply to Consider a Change Managem ...

if your company can afford such an extending/expanding(and they will!) process of managing changes.

In general it is a good idea. Just be aware of the costs that come by with it and ... these process(es) must be S(pecific) Measurable Acceptable Realistic Time framed => SMART

What it gets too is that common sense is to be used. That is for the ones that are updating content/programs and management on how to prevent disasters.


Collapse -


by Shellbot In reply to web cowboys..(my rant abo ...

well, on the upside, i've convinced them to get a systems analyst in to do a review of what we've got..
this is a huge step for them, believe me.

I'm almost out of steam for this week and its only wednesday. I just want to crawl into the corner and sob..
This morning when i got in, inbox full of users saying they can't print certain items properly. Seems the "enhancements" messed around with some permission settings we've got..
i can't fix that, so had to call the "incredibles" to fix it..

ah well, what doesn't kill you can only make you stronger right?

Related Discussions

Related Forums