Erosion of Benefits under HVHC (parent company)
December 2012
• Paid holidays reduced from 13 to 8 per year.
• One of the paid holidays is "Fiesta Day", which is pertinent only to associates in San Antonio. Latham associates are not forced to take Fiesta Day off; rather, they can take a day off of their choice as long as that day is within two weeks before or after Fiesta Day.
• Floating holidays (birthday plus two other days) eliminated.
• Unused vacation can no longer be rolled over to next year. This becomes a big deal in the annual rush (each fall) to get features released for January 1. In addition to working extra hours evenings and weekends during this period, programmers do not have the ability to take outstanding vacation days, effectively losing them.
• Granularity of sick/personal time reduced to 4-hour blocks. If you have an AM doctor's appointment and arrive at the office at 9:30, it costs a half-day.
January 2014
• Flex-time is eliminated. Associates must be in the office from 8 AM to 5 PM (to ensure adequate coverage…). A one-hour lunch is optionally mandatory, meaning you can take an hour for lunch or just work nine hours per day. You also have to be available outside of the 45-hour work week, of course.
March 2014
• Gym and health club memberships no longer reimbursed. The announcement for this was sent just hours after an e-mail was sent touting the large financial reserve the company has.
Dysfunctional Processes
Company culture (in place well before HVHC took over) results in programming requests being thrown over the wall without adequate detail. Programmers spend a significant amount of time doing business-analysis tasks before they can even begin programming.
The very process of determining functional requirements is frustrating, at best. Whether it's due to lack of knowledge or fear of taking responsibility, business decisions are stifled by meetings and lack of consensus, only to be laid aside for a future meeting.
There is a left-hand/right-hand communication problem. Features will often have progressed all the way to QA when another person will voice an objection to the way the feature has been defined. Development time is wasted, QA time is wasted, and more meetings are frantically organized.
On paper, there are scheduled releases to the production environment. In practice, interim releases are hastily pushed through because something was left out of the requirements, a promise was made to a client (without consulting IT), or there was inadequate planning for regulatory compliance.
A symptom of the chaotic release schedule is the fact that there are three separate QA database environments, each with a suite of disparate features designated to an upcoming release (in theory). What you end up with are deployment issues that require extensive troubleshooting, for example because a script has been deployed to database A, but not to B.
Application Architecture
Three separate claims systems, each of which has different business logic. Countless reports, export packages, queries, EDI jobs, all without a unifying vision. Repetition of code and processes create a maintenance nightmare. There is no ERM/CRUD implementation, just a hodgepodge of stored procedures. There is a TON of business logic in stored procedures. There is a TON of client-specific logic in code and stored procedures.
All in all, it feels like you are continuously applying band-aids and choosing the least awful method to get your code out the door.
Attrition
Programmer turnover was fairly normal (perhaps a little high) until the beginning of 2014. In the first six weeks of the year, five .NET programmers left the company. It would not be unrealistic to predict that two or three more will leave in the coming months.
As of May, 2014, there has not been a single programmer hired to replace those mentioned above. The workload of each outgoing person gets transferred to those remaining and it doesn't take many iterations before the stress of being responsible for unfamiliar functionality, on top of your current workload, takes its toll.
