How to deal with a boss who has lost touch with modern software development?

Question

I work (as a junior developer) for a medium-sized company which is the sole market leader in our industry. Our software mainly consists of old code which has been hastily ported/copied to a 90s programming language, with some rewrites in current languages thrown in. The 90s programming language has had no support for a couple of years. The whole thing is a patchwork and requires a lot of work to maintain, let alone add new features to.

The issue now is that our boss (who built up the company as a developer and its status as market leader) stopped keeping up to date with modern software development somewhere in the 1990s. He wants us to add new features unrealistically quickly, with no regard to code quality, maintainability or future-proofness.

Our newest task is an idea which sounds pretty simple, but requires major reworks in our data-access subsystems. It would require months, even without a thorough planning beforehand and testing afterwards. In his opinion this would only require a few days maximum and neither we nor our managers have been able to turn him around.

The project has been running for around a month now, and, while we are making progress in the subsystems, he now wants us to show visible (i.e. customer-visible) progress. This is hard to do, because most of our stuff lies in the underlying libraries. He thinks we are slacking off and wants us to determine daily goals, show him new features daily and keep a journal on what we are doing. This causes a great amount of stress, unrest and partly fear along us developers, because we have to justify every minor step we take and feel that we are no longer trusted by him.

While the obvious answer would be to look for another job (which I am already doing, just in case), I want to deal as professionally as possible with this situation since the actual working environment is pretty nice and I'd like to keep the job for now.

What are our/my options? He isn't interested in reading our code, nor in listening to reasoning from us developer-peasants.

Answer 1

You've stepped into a common situation, much more common than someone outside of software development would think.

If you worked at a trucking company and were promoting using 30-year old trucks you'd be considered insane (maybe?) but things don't work this way in a software company, mostly because nobody can "see" the code - they see the web site or app interface.

Many prominent companies have had trouble letting go of obsolete systems, Microsoft is the first that comes to mind with their Windows Phone 6.0. In many of the cases I can think of the company eventually falls victim to its own "cash cow" or "established ecosystem", eventually being replaced by some competitor's innovative system.

Stale environments in my experiences have shown to be self-promoting: The boss chooses lieutenants who agree with him, they groom and promote similar ideas and middle management people and progressive thinkers are pushed aside, reduced to code monkeys. It costs the business millions to do that but because all the power jobs are kept by people who are afraid to change course of fear to lose their power job. Vicious cycle that doesn't break until to company eventually and inevitably fails (Yahoo? Blackberry). I worked at a large HVAC company and I know for sure one of the projects they've worked on in the past 2 years has cost them over 5mln (my estimate) when it could've been done for 10 times less and 3 times faster.

If the environment you're working in is too stale you should consider where is it you're taking your career. Are you a junior developer learning Fortran/Cobol/VAX...? Are you convinced that if you develop some obsolete skills you'll be able to land another job?

My advice is this: don't try to change the company's course, it has stayed unchanged for decades and you're likely to end up pushed aside. Move on, find another job that will train you in modern skills. And 30 years from now don't be that boss :)

Answer 2

Money.

You need to supply him with appropriate costing as to why his methodology is going to cost more than yours. Why is it going to take months to do infrastructure work? What bottom line benefit is there for him to do this work? I'm talking about cold hard numbers. Why are modern practices better? Why should he care? Where is the benefit to his customers and ultimately his bottom line?

You say he's lost track of practices, well he's likely gained a lot of knowledge on how to make a successful business in spite of those practises. As an engineering team, it's your responsibility to provide him with the data so that he can make his decisions. If his practises are going to hurt his business then that's what he needs to hear.

At the end of the day, if his metrics are features that the customers can see then you have a problem whereby doing non-customer demonstrable work will seem to him to be non-focused on his core goals. You have to talk to him in his language and that language is numbers.

It's all well and good assuming that modern practices will help, but without the data to back it up you're likely to be in a situation where he won't see you as a valuable member of staff.

edit:

I see from your question that he is asking for lots of daily updates, daily demonstrable items, etc. To me, this is very much what you'd find in a modern scrum-like methodology. In fact, I'd go so far as to say perhaps you are misjudging him and his approach. perhaps you should adopt this approach as a way for both sides of the battle to move closer to their goals cooperatively.

Answer 3

I was working for such a company. The problem is that it is very difficult to disrupt and/or kill the cash cow. What I had also observed is that most people had no problem working in a 90s environment being in the 00s or 10s (An interesting question: "Why was this so important for me and not for the rest of the employees there?").

I believe that most of the people in the organisation would say that: "There is a cash flow, the system somehow sells, no-one would want to refactor it in order to make it more modern." Reason is that your boss, over the years has started hiring people that would agree with him (vs the current practices, "hiring yourself" mentality). By now they should be so many that they are the majority. People that cared over the years have probably moved somewhere else, or they have chosen to remain silent.

I disagree with @Preet Sanga, if the owner cared about any metrics, he would have cared in 2010 or in 2005, not allowing the situation to slip in the first place.

When I started complaining about the situation described in the first paragraph, a backstabbing chain of events started which eventually led me out of the company, a good outcome both for me and the company. Based on my personal experience, my advice would be to... leave. :-(.

Answer 4

In regards to this boss having an unrealistic idea of how long the changes should take, I suggest creating a ticket / sub task / 'unit of however you document work that needs to be done' for each component that needs to be changed.

When confronted in back and white with a list of all the components that need to be changed in order to accomplish the end goal, your boss would be more likely to see it will take longer than a few days.

Answer 5

Leave.

Seriously, as someone who spent too many years in this exact situation, this is the advice I wish I could go back and give myself. At BEST you will bring things forward a few years, perhaps incurring the resentment of the powers that be, but almost certainly you will not receive due recognition for your effort. The company will never catch up, because the people running a modern shop aren't going to be holding still waiting for you, and in the meantime you'll be falling behind. It is critical for you at this stage in your career as a junior developer to be surrounded by the right kind of coworkers so that you can grow and develop your skills and develop good habits. The situation you are in is not going to provide these opportunities. In three or four weeks you could be doing work you can be proud of in a workplace you enjoy.

The market has a wonderful mechanism for dealing with "technology" companies that refuse to move forward.

No workplace is perfect, but the fact that you felt the need to ask the question suggests to me you already know something is wrong. Get out as fast as you can.

Answer 6

You're working for someone who started as a programmer and has a lot of knowledge, including knowledge of the failed Netscape rewrite, and how that destroyed the company. He may have read this article. So he may be overlooking the dangers of technical debt, because of the dangers of a rewrite.

So, since he does appear to be using a version of scrum and agile, then work with that. Work out the large steps of what needs to be done, then details of those steps, with estimated times. Include justification for why the steps need to be done, and remember that profitability is as important as maintainability, and code quality doesn't pay the bills.

Ask about the business needs and stresses, and then listen to him. If you listen to him, and try to understand where he is coming from (and he does have knowledge that you don't), then you will get more respect and he is more likely to listen to you.

Answer 7

Fact is, you are working on an old code base that probably over the last 20 years has grown worse and worse, making changes is hard, harder than it should be - and you are not going to change it. The other fact is that whatever your boss tries, adding the new features that he wants will take its time, and nothing your boss can do will change that.

Now if your boss wants daily goals and daily results, give him daily goals and daily results. Take half an hour first thing in the morning to determine what you want to do in that day. That's half an hour where you could have been coding, but that's what your boss wants. Half an hour before you go home, stop writing code and determine and write down what you have done that day. Now important (especially as a junior developer): Keep track what portion of your plan you have achieved each day. Once you've done this for a week, you'll get to know what actually is achievable in a day and change your plans for the day so they match what will actually happen. Your plan for the day shouldn't be "what you would like to happen" or "what your boss would like to happen", but "what will happen". The fear that you may be experiencing is mostly caused by not achieving what you think you ought to achieve - that fear goes away once you learn to plan realistically by adjusting your plans to what you achieve.

Meanwhile, let me guess how much training you get during your job... If it is as much as I think, your working day shouldn't exceed what you get paid for, so you are fresh enough and have time to learn things on your own at home. Especially aimed at learning things that would help you in a different job.

Answer 8

It isn't your job to reform how the business works, that's your bosses job.

You job is to fit in and perform the role as defined by the business.

Don't fall in to the trap of thinking that this job is the only job in the world, and so you need to reform it to make it better.

Recognize that even developers who have have 20 years experience, still fit on a continuum of talent - not all of them are 'rockstar programmers'.

I'm not saying it's impossible to reform this workplace (nothing is), but common sense would suggest that the most reasonable course of action here is finding a job that suits you better with more modern development practises. Your current role will then be filled with less ambitious/more ok with grinding it out, people, or the business will simply fail.

Answer 9

If there is somebody else higher up that you can speak with to explain the situation, then I would advise doing so.

Try to avoid playing the blame game when talking about your manager, instead try to look at it in a more positive light. Something like this might suffice:

"I am worried that X person might not be up to date with current software practices, I believe that this might effect the project negatively in the future. Would it be possible to give X person some more training on modern software development practices?"

If this is not an option then I really suggest you start working elsewhere. It really isn't worth your time working for a company that is stressing you out. You have to ask yourself as well, if the company is working like this now how likely is it that they will be around in 5-10 years time? Basically, is your job secure, or will a competitor over throw them?

Answer 10

It's not your business, it's the owner's business. As you said, you're basically just a peasant-worker. Probably your ideas are good, and all, but from the perspective of the owner - he's just going on what has worked for him - after all, he's the one who built up the business and it makes money. It probably has made him and his partners a lot of money over the years, so why would they want to change it?

Realistically, what you probably have to do is just do what he's asking. It sounds like you are averse to "quick and dirty hacking" but sometimes that's what you need to do.

You can try meeting with him, - perhaps you and your coworkers can sit down with him and amicably explain your side. If you do it in the right way, he might be willing to be flexible. I would suggest this is a reasonable thing to try. But likely not to make a big impact.

This sounds like one of those situations where you have to swallow your pride and just go with the flow. (or get another job if you absolutely can't stand it)

Answer 11

If you cannot change your company - change your company.

If you cannot change the process and technology, leave. You are wasting your time without gaining marketable skills. What you will do after company becomes less profitable, fires junior developers like you, and all your skills are in those obsolete technologies?

Edit: people downvoted this, claiming that it is 3 sentences saying "quit your job".

But I did not said just "quit your job". I said "if your company sucks so badly and you cannot improve anything, and you are not gaining marketable skills is better to quit your job when it suits you, than wait to be fired for incompetence of others". I truly believe that is this situation is better to prepare and move, than wait for the axe.

I was in similar situation years ago (becoming expert in obscure corners of an obsolete technology), even if people in company itself were great.

I was able to find another position in which I learned modern technology, and I was about the last person from the company who left on own terms - most of rest were fired, after they trained they own replacements when company was restructured and development outsourced and switched to contemporary technologies (making whole great team obsolete). YMMV

Answer 12

It sounds to me like you don't want to leave. While I understand that, you also say you are looking, so it's good that you're at least considering it. However, most of the answers here suggest leaving, so I'm not going to talk about it.

The problem you have when talking to your boss is that you aren't providing him an alternative. I'm sure you think you are, but really, you're not. Saying "let's have a 5 minute meeting every day" isn't all that different from what he already wants to do.

If you really want to stay, use some of your spare time (possibly with the help of your coworkers) to really work out a business plan about how you would move the department if it were up to you. And I promise, whether he's read it before or not, he's worried (and rightly so!) about the story of Netscape (I know I'm not the first person to reply to talk about this.

So you need to do two things:

• Write down exactly all the different pieces of the software rewrite to do his change, and how long you expect them to take. This needs to be broken down into small enough bites that he won't think you're just making up numbers, but not so small that it becomes tl;dr. This will take quite a bit of effort to strike the right balance.
• Then, figure out a plan for how to incrementally move the system into the future. This needs to be done incrementally, because they can't just shut everything down for a year.
  • Likely, the first step will have to be breaking the existing software into modules that communicate with each other; not an easy task! However, this is good to do anyway, just to make development easier and separate concerns.
  • Once that's done, then you can start working on migrating each component into a newer version.
  • It is crucial that this part has enough detail for him to see the time horizon! You cannot bring smoke and mirrors to him, because he's been in the industry long enough to be able to identify them.
  • It is also crucial that he has enough details for him to feel that he can summarize the work that you've done to sell the idea to upper management (he will not want you to write the really high level executive summary, so don't do it).

When you finally are ready to meet with your boss, here are the things to keep in mind:

• Do it in private. Make sure your boss does not think that you are actively trying to make him look bad. One idea is to invite him to have a drink with you outside of work to make the whole thing seem less serious and lower stakes than it actually is.
• Do your best to make him feel included. Think of ideas of his and make sure to give him credit for anything he's done or said that inspired a component of your writeup. Meeting with him like this is going to feel a lot like stepping on his throat, so you had better be prepared to massage his ego on the flip side. Also, show awareness that the decision to proceed with your plan is not going to be his alone, and allow him to be the one to present it to upper management if he does agree with you. Do not look for credit here.
• You must come into this presenting as little ego as possible. Make sure it is clear that you are doing this because you feel this is the very best use of your time, the team's time, and ultimately (as suggested in @PreetSangha's answer) the company's money.
• You should also explain how unhappy you are, but not in a woe-is-me way, rather in a these problems are having these specific impacts on morale and as a result, productivity. Try to be dispassionate here.
• And, finally, you must be prepared to lose your job over this. Many bosses don't want to be shown up so thoroughly and will be looking for the first excuse to dropkick you out the door. If this is your boss, then none of the above matters, and the most important thing to do really is leave.

Answer 13

Consider this: you're the junior, the youngest kid in the team, yet you have some grand ideas about how to change things "to be more modern".
That manager has encountered dozens like you before, and they all failed. He has no incentive whatsoever to listen to you, as he knows from decades of experience that every snot nosed junior programmer has a head full of book knowledge and grand ideas about how to "improve things" that he's found out to his chagrin himself over the years simply don't work, or if they work aren't worth the effort implementing.

So even if your idea is brilliant, would work, you're up against that, a set in stone process that's worked for years or decades despite a constant flood of attempts of people just like you to change it.
And worse, they no doubt have had highly paid, very expensive, consultancy firms do audits and write proposals on how to improve things, and they too all failed.
It doesn't matter why they failed, but they failed, and that has created over the years an attitude of hostility towards anyone and anything that tries to change things.

Best you can do is roll with it, go with the flow, gain the trust and respect of the people who are your seniors and do know more than you, and maybe, just maybe, find ways to make tiny little incremental changes in the way things are done eventually. Just make your own personal workflow more efficient, in ways that don't interrupt the project team as a whole, but give people the impression that "hey, this new kid is a fast and efficient worker". Maybe people will look at how you do things and start trying it themselves. That's the best you can hope for, not barging into your boss's office with a head full of ideas and an attitude of "you're doing it all wrong and I'm going to tell you here and now how things should be done from now on" as that's only going to make you enemies.

Again: it doesn't matter if your ideas have merit. Your status means that they won't be perceived as having merit. And there's nothing you can do to change that by having an attitude about it, only time and gaining the respect of your colleagues as somebody who knows what he's talking about MAY do that.

Answer 14

I didn't see this idea in the current answers, but please let me know if i missed something.

Show your work:

If your boss was a developer a long time ago, then they should know what a diff log looks like. Showing the extreme amount of programming it takes to accomplish it 'his way' should be enough more a former developmer to say "Holy cow, that is a lot of change just for my simple request".

Commit often:

If you can show your boss what the work looks like daily, that might even be enough. A possible retort would be if it takes forever just to get one or two lines right, and for that I can only think of one solution.

Commit more often:

Showing how you spent so much time on this one part, with the output logs and errors stacked up might be your solution. It's a ton of meticulous documenting on your part, but saving your job (since everyone else mentioned leaving, so i'm gonna pretend that's not an option) is worth the hopefully short-term effort.

Caveat:

This runs on the assumption that your boss can understand basic programming work, diff logs, stdout and stderr, whatever.. If your boss is so brain-damaged from being management that this is not possible (you should try it even you don't think it'll work), then the only remaining option is to polish your resume'.

Answer 15

I may add another thought: Value Chain (check http://en.wikipedia.org/wiki/Value_chain and the original book by Porter).

I am in a similar situation and I am leaving the company for one simple reason. What you are doing is a "support activity" (in the language of the value chain theory). Coding in a more modern language will not sell more the software, will not get more clients. You may argue that it will save money to the company in the long run, and I agree, but why invest in something that has no "added value"?

Now you have to read what I wrote in the context of the value chain ideas. I am a scientist and a programmer so I know how you feel. But that is the hard truth. Beatiful and modern code doesn't sell more than old and ugly code.

Now before someone criticize me: I also believe that we should code correctly, according to best practices and so on (otherwise I would not be leaving the company where I am working), but that is not how companies value coding... Just my two cents.

Answer 16

This is so common you're more or less describing........

the very nature of the software industry!!!

Essentially, if you can't deal with this or work with it, you can't work in the industry! (Sucks but true.)

Another way to look at it: people who (essentially) make a lot of money in software, who are very successful, are, indeed, the people who can best deal with the issues you so accurately describe.

The absolute bottom line is this: just explain clearly, and as politely as possible - and repetitively:

"That's fine, but it will cost €X. Using this more modern system, it will cost €Y."

For example, a huge innovation in the mobile scene at the moment is "bAAs" (eg Parse, etc and huge innovations like google play and so on). We go in on big projects and simply utterly eliminate the entire server side of a dotcom and just use Parse or whatever. This literally results in 3, 4, 5 server people losing their jobs (and moving on to a better more interesting career!)

You have to remember that "disintermediation" is the ongoing, month by month story of the software business. Looking back 20 years, we'd all make a huge fortune, a prince's ransom, doing something like "adding credit card processing !! to a online shop!!"

It just seems insane now, that one used to be able to charge six figures for that .. obviously anyone's Mom can instantly have the world of online payment processing, completely for free, using google, paypal, whatever whatever whatever. that whole "segment" of the business evaporated completely.

Another incredibly important point for you personally...

You have to ask yourself very carefully - for the sake of your family's finances and so on -

Do you want to spend the next year working on dead technology?

How will that look a year from now when you're trying to find your next job?

"Oh, so you spent the last year working on 10 year old technology that is now even more useless?"

It does not look good.

Consider simply leaving the company. Just very politely explain, look, I love you guys but if I work on 10-year old technology for the next 12-18 months, I've just lost 1-2 years from my career, and programmers have maybe 15 years maximum power in their career at best, so it's not going to be possible.

Then leave, and get a new job this afternoon.

There's so much work around that anyone can get any job they want any time anywhere, so, again - please be very careful about working on "dead technology" at this stage. Hope it helps in some way!!!