I have been in software development for over two decades. I have worked in multiple industries and multiple size companies ranging from 25 people to large fortune 50 companies. Over my career there are two of the worst mistakes I have seen companies make:
- Having your developers do double duty as business analysts
- Having someone who was never a developer over developers
Having Your Developers Double Duty as Business Analysts
Would you hire your accountant to fix your car just because he/she might be able to change his/her oil? No! This is essentially what companies do when they have developers also acting as business analysts or subject matter experts. Developers have enough to remember regarding their craft. You can't expect them to learn the business also. That is way too much information to fit inside a normal brain. Developers also do not need to know the business down to tiniest level of detail like a CEO made need to know. Developers should be given a problem and told to solve it with software. That's it. Any specific background information they need should be given to them. Let them ask the questions and have someone go get them the answers. This is usually a job of a business analyst. This helps the developer focus on creating the best solution using code. Every software development team should have a business analyst or a SME.
Having Someone Who Was Never A Developer Over Developers
I have worked at too many companies that did this. Usually it is someone with project management experience but zero development experience. How can you expect someone with no development experience to understand what developers go through? Someone who has never had a code problem and it literally took two days to figure out that a semi-colon was missing. Someone who has never Googled for two days trying to figure out a solution to a coding problem. Developers must have someone over them that have experienced the trials of being a developer. It's not an easy job. People expect you to do the impossible at times and turn water into wine while still meeting the project deadline. Also developers are unique people with unique tendencies and interests. They are not your typical help-desk or infrastructure IT worker. Developers need people over them who understands them. That is usually someone who was them at one point in their career.
Now that I have said all of that, the problem still remains that most developers do not want anything to do with management. I get it, believe me I do, but someone has to rescue the developers from people that have no clue of the #devlife.
Developers need people over them that:
- They can go to and bounce coding solutions off.
- Can actually do a code review.
- Understands hours DO NOT equal productivity.
- Understands they are not average users.
- Understands the majority of them do not want to talk with people.
- Understands they like what they do and want to do a good job.
- Understands money does not equal job satisfaction
Conclusion
I'm a firm believer in separation of concerns. I believe the only concern a developer needs to have is how to solve a particular given problem using code. If your company is guilty of any of the two things above I would actually consider changing companies. I hate to say that but my experience tells me you can't be in a good situation.
Top comments (20)
"Understands the majority of them do not want to talk with people."
Having also been around some two decades, this is about the only point I cannot agree with.
Developers LOVE to talk. Talk tech. Talk trends. Talk about other interests. Talk about bringing in outside ideas. Hell, look how many tech meetups and conferences exist now! These don't exist just for people to sit around and watch presentations all day, they're very social environments.
LOL. Meetups consists of a bunch of like minded people who like the same thing. Put those tech people in a room with non-tech people I doubt there will be much socializing.
My point was developers tend to want to put on headphones and be left alone writing code. They generally do not want to be PR reps from the IT department.
I can totally agree on this point, I would much rather sit in my corner in my own world listening to music and writing code than have to communicate with anyone.
I second that👍
Good luck with the new job, hope your new boss is a leader and not a manager
Been doing this you a very long time too and I highly disagree that devs should be shielded from business analysis and kept several steps away from upper management.
In fact quite the opposite, your suggestion is a recipe for substandard and failing software projects.
To make high quality software the quickest and cheapest way developers should be intimate with the domain and have a good relationship with the clients and stakeholders. I could write a book on the amount of times i've seen this work beautifully. I could write 10 books on how many times i've seen projects ruined by companies keeping developers in silos and behind layers of communication.
Software design at it's best is an iterative process.. this means involving everyone in the decision making. I think having BAs who don't understand tech who hand down tasks to be turned into code is wrong... tech decisions are better made at the same time as features and ux.
If the devs know the domain they will come up with much better solutions most of the time .. i see this constantly... plus the more you keep your devs isolated the more they think about tech and the less they think about pragmatism and business value.
On your other point, I do agree that it is highly beneficial to have managers who have a computer science background, although in my experience most of the time it's better not to have a manager at all... or if you do, one that actively codes and is more of a mentor than an authority figure.
I see your point. I disagree slightly.
A developer should definitely know his business area. Not as deep as an SME, of course.
If you just "solve problems through code" you miss out on the incredible value that you can provide.
You should definitely be able to answer a lot of questions, just not all the questions.
Also, CEO should not know all the bits and bytes of their business. This is not their job.
Regarding your second point, you have a very problematic sentence there: "They are not your typical help-desk or infrastructure IT worker."
This was never true and it is even less true these days.
You think that tracking down a semicolon is hard? Try doing it across systems, networks and applications. Both of them do it.
You can write the same article you just wrote about and just replace the profession.
I'm sorry but this is exactly why you feel the need to write this piece. Compared to architects for example, you're just a "typical developer".
I do not wish to take anything from your article and I know this was not your intent. 🙏
"A developer should definitely know his business area. Not as deep as an SME, of course.
If you just "solve problems through code" you miss out on the incredible value that you can provide."
We agree for the most part. My point was your team should have a SME and it should not be the developer. You might disagree but I also believe that a developer should not be evaluated on knowing the business area.
Agree completely actually.
The developer should not be evaluated on knowing the business area.
If knowing it turns him into a more valuable developer through his code then and only then should there be a distinction.
somehow your reply doesn't make sense to me. it reads like it's incomplete and unclear.
What makes it unclear and incomplete?
My reply was taking out 2 and a bit points out and commenting on them.
It is not meant to be a complete article in and of itself.
Many developers can be very good with double duty. The development can be much faster if developers know about the business, otherwise, developers will depend on the business requirements, in my experience, most businesses have many logic issues. Many of the business put visual in front of logic, they do not want to see a complicated flow chart.
In my personal experience, the business ask designers to make up some static HTML or powerpoint slideshow, then ask developers to "just plug your code in". I also have seen 1000+ pages of requirements with a lot of words but no logic.
Normally the business does not like to deal with developers because we are not "fun" people. They like to find some "messengers", to become a messenger, this person needs to be "fun" and "positive" with a very basic understanding of development. The worst case is those messengers might get over developers and start to tell the developer how to do their job.
My point is, it will be great for both the business and other developers if this person can do both jobs. However, most business cannot understand this or just simply do not want to do this, especially when the middle-level managers like to keep their "fun" job.
It is hard to find a job that everyone you work with is professionals, especially those days, seems everyone just as "valuable" as developers. But if you are the lucky one, do not leave.
I would add some to your list: Understand one great developer worth more than many so so developers. Understand many developers are actually doing the business job.
I don't really agree that developers and analysis should be totally separate. If a business question were asked and a dev had to answer it, I would listen very closely. Why? Because WE SOLVE PROBLEMS. Code is the easy part isn't it? Eg I have a degree in information systems and management, in which we pretty much trained as analysts, before I went onto become a developer, and I've found that I can run my software company better by always being part of the discussion on processes. In fact, I have found that developers come up with far better solutions to business process issues than any other staff (don't knock it til you try it!). I believe in hiring devs because of their ability to solve problems, and it'd be a waste to exclude them from those discussions. Devs come up with solutions. I would never try to stop that from happening, even if it's not their job to offer one in the first place.
Amen to that! I manage IT infrastructure in a large facility, manage several operations projects, and develop computer vision based applications... With deadlines to meet. My only other programmers are contractors and don't work on site. I'd much prefer to just plug in my headphones and disappear into my terminal, but someone has to keep the wheels turning. No rest for the wicked ;-)
I think as tech gets more diverse, the personality types will change. I was always the most social dev in the room until recently. Now there are all these bootcamp grads who chose to go into tech because it's a good career. Whereas back when I started you mostly went into it due to being a nerd who liked hacking around in your spare time.
I think offering career paths for devs interested in things like business and people is key to keeping them happy. I was miserable as dev work got less business-oriented. I felt too disconnected from what my work was doing. I went into "solutions engineering" (like sales engineering). But it wasn't easy because at the company I worked at, devs were devs and that was the only career path for coders.
You actually made my point. I know a few people that went to school with me for CS and they are now on the business IT side of the house. There is nothing wrong with that. They realized that software development was not for them. The point I was trying to make is just let people who want to be developers be developers.
Great article! Would love to know your thoughts on DevOps and test engineers.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.