The Beautiful Lies and Calls for Help of Software Developers
If you’re managing software developers for the first time, listen for both.
If you’re new to managing software creation, there are some typical pitfalls to avoid. Being aware of them will enable you to achieve outcomes and add value to your organization. And it will save you some stressful moments.
I admire the creative act of software development and the skills of those capable of great work. When I had to manage a development team for the first time, I was intimidated by my ignorance of the work. I had never written a line of code or taken a course on software development. I wasn’t sure I would be able to manage the department without a coding background.
I learned that I could discover the characteristics and behaviors of the folks who did code while I may not have been able to code myself. The management of technical workers CAN be done well by a non-technical manager.
Even without a deep understanding of development work, you can contribute meaningfully by helping your organization avoid typical missteps, manage resources carefully, and choose the right places to add value. My experience has shown me that some typical pitfalls originate as unrealistic assertions, or veiled calls for help. Be sensitive to them, as misleading statements come from modest and great developers alike.
I’ve heard many of these statements repetitively through the last 30 years. Here are some of my favorites.
1. “I could do that in a weekend.”
The statement is an off-the-cuff development timeline assessment for a new feature, functionality or capability. That weekend that has never happened for me. I have heard it many times, but the desired functionality has never arrived on Monday morning. Or by the following Friday. This mythical weekend where new features/fixes are successfully coded is as rare as winning the lottery.
Coders regularly make these statements. It is because, under ideal circumstances, they may be right. But there are never ideal circumstances. Please don’t take this offer without understanding how realistic it is to be successful.
2. “It’s completely modular.”
In the design phase, this statement is probably true. In the beginning, programs and applications and platforms are imagined with Lego block interchangeability. After the second, tenth, or hundredth line of code, that vision is often no longer attainable. And it will never be attainable later. Nothing is as interchangeable as promised.
Don’t ever assume that new functionality or components can be easily “plugged in” and work seamlessly. The design and the product diverge quickly in the hands of the people tasked with realizing them. Have your development architect take extra care with scoping anything destined and hoped to be modular. Plug & Play is often only valid for Lego.
3. “Now the product is debugged, we need to go back into the code and speed it up”.
When you hear this statement, you should hear, “it is time to introduce new bugs as we attempt to streamline functional but clunky and slow code.” The good news is that the new version will be much faster. Bad news is that it will no longer be reliable. You, as the manager, have to decide whether you prefer fast or dependable. Both usually isn’t on the menu.
The only way to accomplish this is to force these steps into an incremental process of improvement and testing. Fence off areas for fixes, test the fixes, re-work for speed. Then move on to the next portions to fix. The natural inclination of doing all the fixes and testing can lead to a rat hole of new bugs.
4. “We may need to tweak the UI “(User Interface)
If the developer is concerned, you should be outright worried about it. The underlying functionality of a system needs a good user interface to be realized by users.
UI development is a specific skill set. If you hear a comment about the UI, it usually means the current team does not have the skills to deliver anything better. If the current team could produce a slick UI, it would already exist instead of the awful one in front of you. Recognize this as a call for help and get skilled people on the issue.
5. “The desktop/server/bandwidth is crap.”
This statement implies that if you weren’t such a cheapskate, your coder’s vision and superior performance would be realized and evident to all. But, due to your cheapskate proclivities, his pure genius is unrealized.
Be careful when poor performance gets attributed to any external factor. Yes, sometimes external factors MAY be the cause. However, hearing this statement should make you focus on things under the control of the developer first.
6. “The existing code is bad”.
It is almost universal that whenever a handyman or the plumber, roofer, electrician, carpenter, assess your current situation, they will speak poorly of a predecessor’s work. Software developers do this as well. It is human nature to critique others’ work if their work is a foundation for your creation. Hint: If your existing code is functional and debugged, be very reluctant to re-work it based on this type of statement.
There’s likely some truth to the declaration. But it is just as likely that the code is just different from how the developer offering the opinion would do it. And that makes it crap to the developer. They know they could do it better and they’re probably right. A different set of eyes and a review of the program will always find areas to improve. Your disposition should be to understand the critical leverage points versus a re-working of a system. Avoid “re-works.” Manage the improvements carefully. The problem frequently arises when the developer goes into a codebase to fix one thing, and spontaneously decides to fix something else.
7. “The reporting function is sufficient”.
If there’s one area where a software user and its’ developer’s views frequently diverge, it is in data reporting and results. The user experiences the value of a program by the actionable reports it produces from usage. To the user, the reports are the product. To the developer, the reporting function is a system component more or less equal to the other parts.
As a non-technical manager, this is the area where you can add the most value. The reporting function showcases your developers’ work. Great reports, graphical and insightful, compel software success like no other items.
Software developers are typically intense people that care a great deal about their craft. That intensity can lead to overstatement of ability or understatement of need. If you’re new to managing software development or developers, you need to be alert to cues that should trigger a bit of translation to uncover the true meaning. Be sensitive to the improbable, responsive to requests, and ready to add value.
