Techniques on showing management how much effort it takes for quality software development?

Question

I'm in a fairly interesting situation. I'm the only software developer in a team of electrical engineers who work on hardware and know how to hack some code in C. I am the sole developer responsible for developing/maintaining/supporting the following:

• DBA of a >2TB SQL Server database with >70 normalized tables, with many of them containing 10s of millions rows, and one of which contains > 12 billion rows of data - I'm responsible for maintaining, tuning, and developing it - writing/tuning queries, coming up with comprehensive indexing strategies, monitoring data growth, etc.
• Separate data warehouse based on above data
• Large SSAS tabular model, based on above database
• Complex, multithreaded, concurrent processes that load data into the database, at a rate of >1 million large files inserted /day, with the data coming from multiple sources. Also responsible for detecting any missing data/data corruption issues and following up with the appropriate people
• Multiple RESTful WebAPI services that power the internal business web apps - some of which are fairly complex, interfacing with other web services within our company and utilizing various design patterns and techniques to help keep them maintainable - Unit of Work pattern, Repository pattern, Dependency injection, automated unit testing, etc.
• All the internal web apps associated with the above database - at least one of which is used by >100 users. Most of the web apps are complex, utilizing ASP.NET MVC5, caching, Typescript, Knockout, Angular, Bootstrap, etc., to provide a dynamic, responsive experience to the users
• Integrating an equally-large set of related data within this next year
• A web dashboard, using D3, Angular, Bootstrap, and other JS libraries- it updates key metrics the electrical engineers want to track as new data arrives
• Creating/maintaining multiple statistics-heavy parameterized reports in SSRS - adding features, fixing issues, etc.

...among other things - this is not a complete list. Only reason I've stayed (mostly)sane is by automating as much as possible, and writing decoupled, modular, testable code that adheres to industry standards and best practices as much as possible.

My manager (and his manager) are very friendly guys and are very capable when it comes to electrical engineering project management, but know next to nothing about software development, and the effort it takes to develop and maintain software solutions that perform well with the data volume we're experiencing. At my recent performance review, my manager mentioned that he thinks my position is a part-time job, and I should be able to handle that and other things - he's baffled when I say that this is too much for one person and I need more help.

They recently hired a guy and said he was to help me part of the time, because he had "database experience" - the last time the guy worked on a database was in 1994, and all he knows is coding BIOS C code in Linux. Management seemed very surprised when he said that it would take him months and months in order to be somewhat productive at helping me.

After laying out a case (yet again) for hiring another senior developer to help me, my manager's manager, who is also fairly clueless about software development, wants to discuss my workload and justification for hiring someone else, as he's not convinced it's necessary.

My question is - what might be some effective approaches, if any, to convince a manager who is not a software developer of the effort and resources it takes to write/maintain the massive amount of code I'm responsible for?

I don't want to come across as complaining, and I don't have 20 hours to explain in excruciating detail everything I'm responsible for and why it takes so long for me to develop new solutions while also maintaining all the existing code and the database. I've tried in various ways to explain how much effort is involved, but I feel like I'm getting nowhere - they compare me to an intern who was responsible for my current tasks before they hired me (the intern coded up a storm, but the code and database "schema" was so atrocious, I had to throw everything completely out and start from scratch) and appear to think that what I'm doing now takes a similar amount of effort and talent. It also doesn't help that I'm in my mid-late 20s, so I don't have a massive amount of seniority under my belt (~9ish years), and thus they don't respect my views as much.

Any suggestions would be greatly appreciated.

Answer 1

Do you use any existing tools for project management of the software development part? My personal favorite solution to demonstrate the actual workload of what needs to be done, is involving them in a process of defining and prioritizing what needs to be done.

Even without applying anything like scrum by the book, I believe some of the core ideas could be useful for someone in your situation:

1. Write down everything you do on a regular basis (the maintaining part) as a list. Write it down in a rather non-technical manner as close as possible to the actual outcome your management will have of your task, e.g. 'Keep System Xyz usable at all times', 'Respond to support requests from xyz users'.

2. Maintain a list of a all new feature / change requests that you currently are aware of, again as close as possible to what management (or users of systems) see.

3. Make realistic estimations about how long each of these tasks will take you. Especially for the regular / maintaining tasks this will show how much time you even have left for new requests.

4. Sit down with your management and prioritized the task. Based on your estimations, you can draw a line in the prioritized list, of what you will not be able to do / to do within the next month. If management is happy with this, they maybe really don't need an additional helper for you.

5. Now, make sure you keep these lists up-to-date. Keep track of bug requests coming in, and how much time they were consuming. Make it transparent to your management what other features or maintenance tasks where pushed behind by this. On the feature / task list this would mean, the 'not possible alone' line would move up, and your management will have to reconsider: Additional help, or x, y, z, etc. will not be done.

In short this means: Making sure the responsibility of what is going to be done is always in the hand of your management (following your good advice hopefully). To do so you make it transparent and easy to understand what is happening, how much time it consumes, and what of their wishlist can't be done.

This can help in many ways: Even if your management didn't have a budget for an additional developer, using your list of what should be but can't be done by you alone, they can calculate the economical loss that means, and this could quite likely free the budget for more help.

In either way, the main goal for you should be to maintain peace of mind: Your job is to develop, and to make transparent to management what management needs to make their decisions.

In my experience the worst thing of being overwhelmed with work and requests, is the bad feeling of not even knowing if you do the right, most important thing or if it will be even appreciated in the end.

Btw.: As a software developer I know that time estimations can be a huge trap. In doubt, be rather a bit more abstract and keep track of what areas of tasks (maintenance, bugfixing, new feature requests) are consuming in terms of time.

Good luck anyway!

Answer 2

To request additional help on any given capability, you need to understand fully the other side of the equation.

1. The Salary, Wage, and Benefit line is likely the most expensive cost your organization has. The SWB is typically the first area to attack when driving costs down because it typically has the biggest impact and there is, truthfully, usually a lot of waste there.

2. There is a constant pressure to improve, which means doing more with less, essentially.

3. Of any given team, you will typically see a few hyper performers who deliver the most and most who deliver marginally to just okay. And from an individual standpoint, humans are the least reliable, which means performance, even with the hyper performers, fluctuates up and down the performance range in a very dramatic and random way.

4. While unproductive time is a given and normal and can be quite healthy as it relates to performance, too much unproductive time is a killer. And a lot of this is perception.

5. Parkinson's Law: work expands to fill time. Student Syndrome: we procrastinate. Managers know this so forcing a constrained resource situation helps mitigate that.

6. Results speak volumes: if the organization is getting its output at the quality level they expect at their current cost level, meeting the timeline most of the time, and there is no evidence of low morale, high attrition, or other negative side effects, then there is nothing to fix.

Based on these things, and there are likely more, you need to build your case in the most objective, unemotional way and stay consistent on message. And your case needs to address the above things in an indirect way. In other words, your case needs to support the organization's goals of maintaining and growing profit, maturing capability to even higher performance, innovation, growing revenue, doing more things with less. So you are asking them to spend more money and, by doing so, you are going to save more money.

Right now, your list is coming across as merely complaining. How are you perceived? Are you a hyper performer? Do you spend just a little much talking at the water cooler? Are you a 40 hour guy and then you disappear? Are you forever labor or can they see you as a leader of organizations in your future who will one day say no to more labor when a 20-something year old starts to complain.

Answer 3

Sometimes the simplest way out is to make them realize the

• Cost of failure
• Time take to recover from a failure

Once we attach numbers to these two metrics, managers pay attention (No offence but I guess it is justifiable as economic benefits needs to be established) Most of the automation should be marketed to management post educating them on the above two metrics. Hope this helps