120

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.

Jim G.
  • 14,663
  • 11
  • 70
  • 79
user128738
  • 1,319
  • 2
  • 8
  • 5
  • 12
    In the spirit of SO, what have you tried so far ? Did you make any kind of easy to understand documentation or presentation which clearly shows why the current system is flawed and how its not extensible ? Can you show him how the current system will fail for anticipated features ? – Erran Morad May 03 '14 at 00:08
  • 19
    Isn't (wasn't) your boss a developer? --- "In his opinion this would only require a few days maximum" --- Tell him to grab a keyboard and write it in a few days maximum. – Daniel Mar 09 '17 at 17:29
  • 1
    It doesn't address how to handle the boss, but for a starter you should be sure that you're applying the guidelines in Refactoring is About Features. – Wildcard Mar 25 '19 at 23:24
  • 1
    I don't know what exact sector you're in, and actually I don't precisely know about the 90s because my first job started in 2000. But I'm slightly baffled by the idea that the time to deliver new features was less in the 90s than it is now. Quite the reverse as far as I know. So, why is the boss (with their 90s mindset) under-estimating that time? It sounds like, while your boss may indeed have an issue with modern methodologies, the relevant issue is that the boss massively underestimates how complex and intractable the code base has become over time. – Steve Jessop Jul 07 '20 at 15:27
  • 2
    @ user128738, I'm way too late to this party but i would really love to know what is this "90s programming language". I mean, VB is from the 90s but Java is also from the 90s. – osiris Apr 15 '22 at 18:09

16 Answers16

90

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.

Preet Sangha
  • 2,515
  • 1
  • 19
  • 19
  • 6
    +1 "he's likely gained a lot of knowledge on how to make a successful business in spite of those practises", and your points about the daily updates are good too... Excellent answer. – mxyzplk May 01 '14 at 15:20
  • We actually introduced Scrum into our team, but our managers told us not to be not too open to it, since our boss considers it as "waste of time" in which we "could actually have some coding done". – user128738 May 01 '14 at 17:28
  • @user128738 So I don't see the issue. You as the engineering team are able to introduce modernisation without it being perceived as impacting his goals. Why can you not continue in this approach while at the same time demonstrate value for him? – Preet Sangha May 01 '14 at 20:47
  • 6
    I'm putting a -1 on this answer, as I don't believe it's the most effective answer. Yes framing things in terms of money is a good way to present things to your boss. However, for changing this particuarly situation, this isn't going to be nearly as effective, as say, leaving. – geekrunner May 01 '14 at 22:25
  • 26
    @geekrunner - in what way does leaving answer the question? It might be the best thing for the OP's sanity, but it's not the correct answer for the question asked which is how to deal with the boss. – Preet Sangha May 01 '14 at 23:35
  • 10
    If the question was 'My car caught fire, and is now a melted piece of rubble, how do I make it work again?' - you could give a detailed answer about how to reassemble it and make it work, or you could say 'Get a new car'. – geekrunner May 01 '14 at 23:41
  • 3
    "he's likely gained a lot of knowledge on how to make a successful business in spite of those practices". I'd actually argue that's irrelevant. You can get away with poor practices/ seat of your pants stuff when you're first starting out, but as the company gets more successful the software invariably gets more complex, which common best practices are meant to help deal with. Thinking that you can operate as a startup forever is dangerous and will cause major issues. I'm actually dealing with this currently to some extent. – Andy May 02 '14 at 00:25
  • 3
    @Andy - I'm not saying that that his way is best going forwards. I'm saying that he feels that his concerns are not being addressed by the engineering team. He thinks he's being customer focussed, but it could be he needs to understand how continuing in his current way needs to be improved but in a language that addresses those concerns - his bottom line going forward as well as customer facing demonstrable code. – Preet Sangha May 02 '14 at 01:32
  • 1
    The problem with this argument is that anyone who can't be convinced that developing the software with modern best practices is worth it in and of itself isn't going to be convinced by a cost argument. They're already thinking short term, and in the short term, Boss's ideas are cheaper. I've been fighting shortsighted budgeting for years, and never have I ever seen someone who is focused on short term costs be convinced by the prospect of long term savings. – asgallant Feb 11 '23 at 01:36
82

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 :)

Malice
  • 105
  • 4
user19202
  • 1,376
  • 1
  • 10
  • 11
  • This actually describes the environment pretty well. It's not as bad as Fortran/Cobol, but still far too limited to keep up with modern requirements like touch-capability, integrated OS look-and-feel and even modern OS compatibility. – user128738 May 01 '14 at 17:32
  • 40
    "If you worked at a trucking company and were promoting using 30-year old trucks you'd be considered insane (maybe?) " - You've never rented from U-Haul, have you? – Wesley Long May 01 '14 at 21:39
  • 9
    +1. I did exactly this last year and my new environment promotes modern thinking, newest tools and the best practices. It is making me a better engineer and a much happier employee. – Gusdor May 02 '14 at 08:31
  • 1
    I never quite got that so many programmers always want to do code refactoring. Seriously, I hate writing code which adds absolutely nothing, just to have a cleaner coding style or whatever. Of course there are situations where you have to completely replace code, but in most cases I would say it is good enough to replace parts of the code or add new functionality using a new technology and have some interfaces. – dirkk May 02 '14 at 18:27
  • And actually - having Cobol or Fortran knowledge would be a big plus, if you like the languages (or at least can tolarate them). Such programmers are in high demand and are very well paid, especially in a mainframe or big business environment. – dirkk May 02 '14 at 18:28
  • 1
    thursdaysgeek has linked this article already. Read it. Also this. Don't confuse innovation with the inability to recognize value in the work you've already done. Or course you're not wrong (except about Cobol, you're really very wrong about that, I mean in general) but its just not as simple as the old boring and obsolete hindering the fresh and new. – Nathan May 03 '14 at 00:01
  • 2
    @dirkk: refactoring for the sake of refactoring is a horrible idea. It's not worth disturbing a working system just to make the code prettier. But refactoring definitely has its place. I've seen an old bacnet com system that was designed around 1200Kbps modems, making it extremely cryptic and only understood by a few DLLs written long ago in C, causing all sorts of problems when you try using them in a C# MVC front-end. There's a time and place for refactoring, don't ignore it or your future projects will suffer – user19202 May 27 '14 at 17:04
  • @NathanCooper: The problem arises when the source pool of developers for a particular tech dries up. If you don't keep at least modest pace with modern technology you may find yourself losing to an agile competitor. The article lists rewriting attempts gone wrong. But one can only imagine what would've the mobile landscape looked like if Microsoft had recognized the need to rewrite WinMo as soon as they laid eyes on the iPhone, similar to what happened to Android http://tech.fortune.cnn.com/2013/12/20/apple-google-vogelstein-dogfight/ – user19202 May 27 '14 at 17:08
  • 13
    Just a side remark: COBOL is really great for 1) moving blocks of data and 2) adding numbers. Surprisingly many tasks boil down to this. Just because code is old, does not automatically imply that it is obsolete. – Thorbjørn Ravn Andersen Jun 24 '14 at 16:28
  • 14
    @ThorbjørnRavnAndersen if you just founded a company that will be doing The Next Great Thing of the Interwebs would you use Cobol? Not just from a technological perspective but from business one too: finding skilled and cheap workforce. Yes, it's obsolete. – user19202 Jun 25 '14 at 14:29
  • 1
    @user19202 Here is a great story about how choosing the correct computer language made the author successful and earn a lot of money: http://www.paulgraham.com/avg.html - in his case it was Lisp (which incidentially is also old). Also startups do not need to find a skilled and cheap workforce - they need a free electron (http://randsinrepose.com/archives/free-electron/) to really shine. – Thorbjørn Ravn Andersen Jun 25 '14 at 16:17
  • 9
    @ThorbjørnRavnAndersen to shoot a target on a battlefield you could still use a crossbow and you can argue it's superior because it's stealth etc. And yet it's still obsolete in modern combat, regardless if it's used on a very rare occasion – user19202 Jun 25 '14 at 16:27
  • 5
    @user19202 I have worked for nine years in a company where the core product was written in COBOL and the speed of the language in moving data and adding numbers, combined with the flexibility of the underlying operating system allowed us to make a living simply by being able to highly customize the product to each customers liking and stil keeping the complexity down. As I am a Java programmer writing the programs to complement the COBOL programs I fully understand the strengths and weaknesses of both. – Thorbjørn Ravn Andersen Jun 25 '14 at 18:05
  • 4
    Note that if you don't mind maintaining ancient code, it's getting to the point where folks fluent in COBOL are rare and valuable... – keshlam Aug 24 '15 at 14:54
  • @keshlam compare that with the tag "handmade" on various goods you can buy. Chances are the artist who handmade, say a dining room table, made good money on it. Yet most money on dining room tables overall aren't made by craftsmen but by industrial establishments that keep their manufacturing chain at least reasonably up-to-date. And then there are complex goods like computer chips that can't even be made with obsolete tools. Same goes for software - obsolete tech may make some niche money, and there are things you can't build with it (reasonably) – user19202 Aug 24 '15 at 18:06
  • 2
    I'm not advocating for old tech -- far from -- but a better analogy would be the guys who make museum-quality repairs to antique furniture. Modern furniture works just fine, and is much cheaper. But if you've got an old piece and it still does what you need from it, you may want to continue using it because you're comfortable with it and finding a replacement that coordinates with the rest of the suite would be more nuisance than you can justify right now. – keshlam Aug 24 '15 at 19:10
  • My money is on Visual Basic. – Grimm The Opiner Nov 20 '17 at 09:29
  • 1
    Let us also not forget the issue that if you're very experienced in using a hammer, suddenly everything starts looking like a nail... – Cronax Nov 22 '17 at 14:24
  • 2
    @keshlam we ancient ones, those of us who speak of tape drives, punch cards, and floppy disks retain much wisdom – Old_Lamplighter Mar 21 '19 at 15:50
  • 3
    @user19202 if you just founded a company that will be doing The Next Great Thing of the Interwebs would you use Cobol? Hopefully no, and why does that matter at all? Where did you get the idea that they will be doing The Next Great whatever? Most people in the field know that there is no best or worst language in absolute, it's always relative to the particular goal to achieve in that particular scenario, and of course there are plenty of contexts where the language that is the best fit is an older one. Do you really find that strange? – SantiBailors Aug 11 '19 at 06:48
  • @SantiBailors first you say "hopefully no" and then "why does it matter" - so you clearly understand why it matters. Not because of language being better or worse, but because of market context. Using a modern language has, often times, technical advantages - tooling, libraries, etc - so it would probably be useful. Being able to hire people to join the project - even more useful. – user19202 Aug 12 '19 at 17:38
  • 2
    @user19202 Hopefully no because in the situation you described it would be a mistake, and why does it matter because that situation is different from the situation being discussed so whatever one does in that situation is irrelevant for the topic at hand. – SantiBailors Aug 13 '19 at 16:10
  • @ThorbjørnRavnAndersen This is a self-fulfilling prophecy, like an industry full of nail-hammerers saying "surprisingly many tasks come down to just hammering nails into things". Yes, because those tasks were defined by nail-hammerers in the first place, new tasks are interpreted in terms of nails and hammers, and tasks that couldn't be solved with nails and hammers were simply not undertaken. – JounceCracklePop Jun 03 '21 at 22:03
  • @JounceCracklePop Not quite. Surprisingly many of the things somebody is willing to pay for having a computer do is adding numbers and moving data around. I am not advocating choosing any particular language or platform in general but as always use the best tool for the job - for this COBOL is very good. Simple as that. In my experience this is what "enterprise" usually mean - something you won't use trigonometry in... What would you suggest would be a better choice? – Thorbjørn Ravn Andersen Jun 03 '21 at 23:49
  • @ThorbjørnRavnAndersen Surprisingly many of the things people are willing to buy from supermarkets are those things already on the shelf. Before you talk about what "enterprise" systems are like, ask: does anyone like the current state of enterprise software? Do people really just want faster horses? We're not doing it right. I've spent the last 12 years of my career challenging the conventional wisdom of what an "enterprise system" means, with success. The best tools support lots of varieties of abstraction, and that doesn't sound like COBOL. – JounceCracklePop Jun 04 '21 at 21:31
56

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. :-(.

Dimitrios Mistriotis
  • 2,371
  • 15
  • 21
  • 12
    "People that cared will have moved somewhere else" .. yep, seems like the company has a self-inflicted "Dead Sea Effect" – Carson63000 May 02 '14 at 06:37
  • 6
    +1 for "backstabbing chain of events happened". Sometimes rocking the boat ends up with you in the water. And then you find a much better boat. – Hannah Vernon May 02 '14 at 20:44
  • Better suits comments: There was a nice talk (have lost the link) from a great guy that was running a consultancy somewhere in the US. He had "trap" questions like: "Modern software development practices are important for me" and similar in order to filter out people that were not in-place with his business (he was mostly maintaining old-old software). It is the responsibility of HR (or of a HR-person) to communicate that in advance and inform the candidate. – Dimitrios Mistriotis May 08 '14 at 09:52
  • This seems common with US automotive companies. They just go bankrupt about every 10 years and they get loans or free money from the taxpayers. And it happens over and over and over. – user77853 Feb 20 '23 at 19:14
42

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.

AfterWorkGuinness
  • 697
  • 1
  • 5
  • 15
  • 20
    This is a good point. Making a list of what it takes to get the job done can be a sanity check for both sides. I some times find what I originally thought would be a major change can be accomplished relatively easily and sometimes what appears to be a minor change requires a complete overhaul of the current process. – IDrinkandIKnowThings May 01 '14 at 17:47
  • Provided item one on the list is not, "rewrite everything we touch in a proper 2010s language instead of the inferior 90s language you decided to use, because we can't be expected to work on that nonsense". The boss won't accept that this is truly necessary, and will start muttering about the youth of today not knowing they're born. – Steve Jessop Jul 07 '20 at 15:34
24

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.

Paul
  • 357
  • 1
  • 3
14

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.

thursdaysgeek
  • 46,181
  • 21
  • 99
  • 168
  • He doesn't use an agile model and only"suggested" it because we weren't getting ready by his schedule. He actually has good ideas. The thing we are working on is a pretty good thing, since it works around some possible future integrity issues, however it is simply not as easy to implement as it sounds which he in turn refuses to acknowledge. – user128738 May 01 '14 at 17:35
  • 6
    I always love managers who think agile means "same work but faster", combatting managers on realistic deadlines is a pretty common problem in this industry, and one most of us cannot escape. In your case it sounds like your boss is already to entrenched in his ways that the only way he'll change is when it's noticeably affecting his bottom line. (Not money lost from taking too long to develop rather, when some competitor zips past you and starts chipping away at his customer base) – Eric J Fisher May 01 '14 at 18:11
  • @RualStorge that's a valid point, but his fear could be the opposite and also valid point. So you need to communicate better to understand where he is coming from, and use the tools he understands to make your point. – thursdaysgeek May 01 '14 at 18:14
  • +1: Many managers are ignorant of the second system syndrome. http://en.m.wikipedia.org/wiki/Second-system_effect – Jim G. May 06 '14 at 01:16
6

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.

gnasher729
  • 617
  • 4
  • 3
4

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?

Carwyn Nelson
  • 181
  • 1
  • 8
  • Unfortunatly, he is the "highest" person in the company. I could probably talk to the board of directors, but I don't know if that is a good idea in my low-key position. – user128738 May 01 '14 at 12:16
  • I have added a little bit extra to the answer, which I hope helps a little bit. Like I have said in the answer, it doesn't seem like it's worth working for this company. You might be best off looking elsewhere. – Carwyn Nelson May 01 '14 at 12:19
  • 3
    board of directors is probably on the same boat as the owner. the owner built the business up and it makes money, so why wouldn't they be happy continuing to do the same thing? – Michael Martinez May 01 '14 at 19:27
4

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.

geekrunner
  • 1,981
  • 3
  • 14
  • 28
  • 1
    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 This is the type of thinking that stifles innovation and out-of-the-box ideas that leads to stale situations that OP described. If you don't like where you are, either try and change it, or failing that, leave. – Douglas Gaskell Nov 22 '17 at 19:16
3

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)

3

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

  • 2
    People don't like simple 'quit' answers here, which IMO is a bit unrealistic, as often 'quit' is the best advice for that situation. – geekrunner May 02 '14 at 00:39
  • 4
    @geekrunner - Indeed, sometimes quitting is the right answer, but considering the permanent financial and career implications of doing so, many community members feel that a very strong explanation, even one backed with professional research or citations, is in order to prevent just telling folks to quit and give up. Peter, check out this Workplace SE meta post for more details on that discussion. Hope this helps. – jmort253 May 02 '14 at 02:54
  • @jmort253 Yes and meta-post clearly outlines that saying 'Quit your job' is an acceptable answer in some situations. – geekrunner May 02 '14 at 03:02
  • 2
    @geekrunner - sure, but this answer does have a feeling of "me too" about it. – Carson63000 May 02 '14 at 06:41
  • @geekrunner I think "Quit your job" can be an acceptable answer but is likely to attract downvotes if it's only three sentences that say "Quit your job." – starsplusplus May 02 '14 at 09:20
  • 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". – Peter M. - stands for Monica May 02 '14 at 12:44
1

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.
durron597
  • 856
  • 1
  • 8
  • 17
  • You've prescribed a very reasonable course of action, but just as you said, it's a lot of effort for an uncertain return. – Jim G. May 06 '14 at 01:20
0

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.

jwenting
  • 4,493
  • 1
  • 17
  • 17
0

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'.

vulpineblazeyt
  • 321
  • 1
  • 5
-3

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.

starsplusplus
  • 1,521
  • 17
  • 21
Umberto
  • 95
  • 1
-3

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!!!

Fattie
  • 32,594
  • 12
  • 67
  • 99