They manage by the numbers, but don't understand the impact on them from their actions
So our management team uses numbers to guide them. How many open defects in the release we are working on, how many in the prior one, how many hours spent developing, how many working production issues. We pions have to account for our hours per project, per task, and by the GL category resulting in us having to log them into 3 different systems in order to supply everyone who wants the information. We are told to lie, there is no other word for it, in how these numbers are accumulated. This is done by waiting until a bunch of un-related issues pile up and then management 'decides' that they are an emergency project that needs to be addressed, but because it is project the hours can now be depreciated, reducing the 'cost' (tax burden) of fixing them. But it skews the project vs defects hours ratio making it look like we are making more forward progress than we actually are. (It also results in the clients having to live with ongoing issues for much longer than they should, but who cares about them - they just pay the bills.) They will also rework defects into projects for much the same reason to allow the hours to be depreciated.
Early in 2021 it was decided to reduce expenses by releasing the offshore contractors we had working to build up our automated testing effort. It was also decided to have that work continue on, being done by the full time staff. What we, the development staff, didn't understand was that there were 20 development contractors experienced in automated testing working on this, plus 4 contracted supervisors paired with 4 QA analyst employees. The 4 employees were retained the 24 contractors were all let go. So the work of 20 full time developers working on test automation was dumped on the 45 developers in our group. Until today, I did not know that 24 people were let go when the contractors were let go. What happened over the 10 months after that event is that the director of software development, the lead designer / developer for our database, the number 2 developer for our database, the primary developer and maintainer for our code generation, both of our MSSQL interface experts, the supervisor for the user interface development, and 4 business functionality developers all left for other companies. The database people all worked as an insular group due to the way the lead functioned (which had always been a source of friction between the various work groups) and he would have been informed of the decision shift the QA work to developers as soon as it was made. He and the director (his immediate supervisor) were friends outside of work and the director recruited him into the company. What I have realized this evening is that all these people moved on because in part because they knew what was coming and it incentivized them to search for their next position.
So we have the work that was being done by 20 contractor developers that is now to be done by the 35 of us developers who are currently employed. We have 15 open positions with 10 being software engineering positions. The goal is to continue to implement test coverage at the prior pace, and even if we fill them all of the open positions it would still take 40-50% our the developers time to produce the same results as the contracting group that was let go. And that is if we are as productive as the group of experienced automated test developer that was let go. But somehow management has convinced themselves that we can do this allocating only 10-15% of our time, because "we are the developers that are creating the application code being tested." The problem is, we are all being assigned automated test cases to be created in the existing application and user interface areas. For some of us, myself included, this is an area of the code I last worked in 10 years ago, as I have been working back-end interfaces and database interfaces since then. Oh yes, all of this work is being tracked within our existing project work instead of being broken out into a separate project or accounting bucket, resulting in the numbers looking like we are making forward progress when in fact all we are doing is back-filling tests in existing areas and not improving the product in any way.
posted by MrPopman @ 10:03 PM
0 comments
