22

I've worked for two years in a great Investment Bank.

I made some technical projects with the desire of creating code the most optimized, respecting the adapted good design patterns, SOLID principle, law of demeter and avoiding all sorts of duplicate codes ...

When delivery in production => zero bugs, all has happened as expected.

But, a majority of developers came to me in order to precise that all my code is too complex for reading comprehension. I listened for instance : "make some if and instanceof, forget polymorphism so that it will be very easily to correct emergency production bugs". I didn't prefer to answer ......

Knowing these developers are not curious at all, refusing efforts to understand a good design (for instance, 90% of developers don't know what is a Strategy Pattern and make procedural code and never oo-design because they want, they said, simplicity), my project managers told me that I am really in the wrong way and too idealist for the Bank world.

What would you advise me ? Should I keep desire of really good code or adapt me to majority of developers who are, I repeat it, really not interesting by design code that is according to me, all the beauty of our developer job.

Or in the contrary, should they learn basic OO principles and best-practices to adapt themselves to my code ?

Improve this question
13
  • 19
    It is hard to soar like an eagle when you work with turkeys ;-)
    – JonnyBoats
    Dec 29, 2011 at 0:46
  • 8
    Change your organization or change your organization. -- Martin Fowler
    – Don Roby
    Dec 29, 2011 at 2:19
  • 9
    @Mik378 You may have a communication problem. If you document your code as sloppily as you wrote this question (and the more OO "cruft" there is, the more documentation you need, so that people know what this ITradeSettlementVisitor interface is supposed to do), your peers are right to complain. It's one thing to write beautiful code which you like, it's quite another to structure and document it in a way which makes it accessible and useable for others.
    – quant_dev
    Dec 29, 2011 at 10:10
  • 2
    @quant_dev: I think you're assuming a bit too much about Mik378. His question doesn't seem poorly worded to me; he is just not a native speaker. I dislike verbosity and overengineered design in OO as much as you seem to do, but the situation Mik378 describes also rings a bell: I've worked with way too many programmers who couldn't understand simple stuff such as boolean expressions (so they would write "if (exp) then True else False")... It's likely that this sort of people would also be scared by design patterns, polymorphism, and would therefore revert to plain old procedural code.
    – Andres F.
    Dec 29, 2011 at 15:28
  • 3
    I strongly disagree that keeping the code simple and easy to maintain for your coworkers is being lazy as stated in the title.
    – user1249
    Jan 2, 2012 at 12:11

11 Answers 11

Reset to default
21

my project managers told me that I am really in the wrong way and too idealist for the Bank world.

GTFO!

Time to leave and pity them. Why should you give a fuck? You know it'll cost them money in the long run with their incompetent staff. This ain't a game of technical discussion. This is about politics. Have them train the other developers or GTFO! If you haven't got enough political weight, then GTFO! Search for a company with better practices.

The only reason to stay there is an adequate compensation for your headaches. So they better pay way above average or GTFO! I doubt you can grow there as a software developer as well. Growth in our profession is mostly achieved by working with people who are better than you and who encourage best practices. And the better you are, the higher is your market value to companies who care.

Yeah, I know this ain't one of my usual answers but really, if you can't play the politics game in this company, GTFO.

What would you advise me ? Should I keep desire of really good code or adapt me to majority of developers who are, I repeat it, really not interesting by design code that is according to me, all the beauty of our developer job.

I would not work for a company which wants me to provide suboptimal solutions. I wanna carve my name into the software. I want to be proud of it. I don't write procedural applications in languages based on the OO paradigm. I believe in high quality software and if the company doesn't, I'll GTFO! Hope you got enough "fuck you money".

Improve this answer
5
  • 4
    +1 - Once it occurred to me what GTFO was... (urbandictionary.com/define.php?term=gtfo)
    – Reddog
    Dec 29, 2011 at 2:05
  • 2
    @Falcon I totally agree with you and it's a pleasure to find people sharing my idea; and specially when you say : "Growth in our profession is mostly achieved by working with people who are better than you and who encourage best practices." The most amazing and the real frustrating is that I'm the younger developer and I do not really learned from older ones. Thanks for your answer:)
    – Mik378
    Dec 29, 2011 at 7:16
  • +1, I completely agree. This bank just doesn't seem like a good work environment, and its problems seem unsurmountable: bad programmers, bad management. GTFO indeed!
    – Andres F.
    Dec 29, 2011 at 15:32
  • 2
    @Mik378: Your current employer is unable to fully use your abilities, and consequently will not be able to pay you what you are worth. A better organization will be able to get more value from you and can pay you more.
    – kevin cline
    Dec 30, 2011 at 10:52
  • +1, If could give you more upvotes, you'd get a 1000 from me. Having worked in an investment bank myself, I know exactly what Mik378 is dealing with. It's a breeding ground for toxic behavior, polarity responders and egomania. Not an idea environment for promoting technical excellence.
    – Desolate Planet
    Jan 2, 2012 at 20:12
18

Tough spot. I think you can go two ways in parallel, standing your point and showing will to compromise:

  • This is about money. As any dev job in fact, but since you emphasize the bank environment, this should work even better ;). Show them that your style saves money. Find an example of how a change in requirements could be done really easily because of your design. Try to find a piece of other code (you have to make sure you don't get too aggressive here, but hey, it's about comparing styles of code) which is prone to break soon, and show them how you don't have to care about such problems because your code is better quality to begin with.

  • This is about money. What if your coding style in fact costs money? It may well do, if other people spend more time trying to understand your code than what's being saved by proper design. You may be doing the right thing technically and still not contribute positively to the team effort. Also, it's possible to overdo OOP design. I'm with you on the "good design is beautiful" side, but I'm trying to make you aware here of their point of view and how they may actually be right from their perspective. In parallel to the previous point, try to find a spot where you overdid it. That gives you some room to maneuver: You can say, ok, I can be a bit more pragmatic here and there, but look, there's also places where this code is really better. It also helps you get into a more cooperative mindset if you try to put yourself into the other guys' shoes.

Improve this answer
11
  • Thanks for your developped answer. I've noted your advice :)
    – Mik378
    Dec 28, 2011 at 23:28
  • I'll add to this the simple FizzBuzz problem. Write it in Java and then do it again in a TDD manner, becomes unreadable all of a sudden doesn't it ;-).
    – Martijn Verburg
    Dec 29, 2011 at 0:11
  • @Martijn Verburg - Do you think TDD leads to unreadable code?
    – Don Roby
    Dec 29, 2011 at 2:15
  • @Don Roby - at times yes, especially when dealing with something like FizzBuzz in an OO language
    – Martijn Verburg
    Dec 29, 2011 at 9:20
  • +1 @Nicolas78 "Also, it's possible to overdo OOP design" - e.g. making primitive data types Objects like int for example.
    – therobyouknow
    Dec 29, 2011 at 11:37
16

But, a majority of developers came to me in order to precise that all my code is too complex for reading comprehension

Has it occurred to you at all that they may be right?

I worked with someone who put a lot of effort into writing code which he described as elegant. He spent a lot of time decrying other people's work as not being elegant. When it comes to be necessary to maintain code his code is not the code I would chose to be modifying. It is so precise and exacting that changing it is deeply fraught with danger.

The interesting word you mention here is "complex". Code which can be described as complex can rarely be also described as particularly good.

Improve this answer
6
  • 1
    +1000 Agree. Code is for humans. The caveat being, of course, that the other coders should be able to read what most coders write. Anyone who doesn't understand the basics should be made to improve.
    – Iain Holder
    Dec 29, 2011 at 10:32
  • 3
    +1 @temptar for "Has it occurred to you at all that they may be right?" and " Code which can be described as complex can rarely be also described as particularly good."
    – therobyouknow
    Dec 29, 2011 at 11:38
  • 2
    -1: I don't think they are right, just a bit senior, and I think a closer reading of the question makes that obvious. The key phrase from the OP is "avoiding all sorts of duplicate codes ..." He's trying to DRY up the code, but doing so requires a sophistication his colleagues apparently lack. He also quoted his colleagues suggestions to "just add an if ... instanceof". That also tells me that the OP is on the right track, and his colleagues are building a big WTF.
    – kevin cline
    Dec 30, 2011 at 10:44
  • what has me worried is the "Too Complex" OOP can be a good thing but it can also get very complex very fast. I suspect the Original Poster may have drank the OOP cool aid and has not understood that it is not always the best way to code, and that he may be introducing a lot of extra complexity where it is not needed.
    – Zachary K
    Dec 30, 2011 at 12:00
  • Sounds like this coworker of yours do not have his tests in place for future maintenance. You may want to bring that up with the project manager.
    – user1249
    Jan 2, 2012 at 11:53
10

Victorian era furniture makers (at least, those whose work we still see today) were real craftsmen, what they made was functional, beautiful, well crafted and designed and built to last a lifetime. However in the last 150 years, the world has changed. Not many people are prepared to pay for such craftsmanship, when cheaper alternatives are more commercially pragmatic when buying a dining room table.

Many programmers want to be the craftsmen of old, unfortunately, commerce dictates that this cannot happen all the time. You have a choice, adapt or leave. There are companies that want craftsmen, but they are massively outnumbered by those that want products that mostly work, cheap and now.

The hint to me that you are not suitable for most commercial software development is the "When delivery in production => zero bugs,". Not even Nasa achieved that with the space shuttles.

The only places where you attention to detail, and therefore initial cost, is likely to be acceptable is level 1 life critical systems - e.g. Avionics/ Aerospace, Automotive, Military and Medical.

Improve this answer
2
  • 1
    +1 @mattnz for " You have a choice, adapt or leave. "
    – therobyouknow
    Dec 29, 2011 at 11:38
  • 2
    I disagree - this is a bank. They tend to like that there is no bugs in their software as errors may grow quite expensive. Also solutions may run for years or decades.
    – user1249
    Jan 2, 2012 at 12:01
2

The problem is that you're working in the wrong place. It sounds like you're a very academically inclined programmer. You won't do well in the environment you're in and it's quite likely that some excuse will invented to get rid of you and your "too complex" code. You may be given junk assignments and/or given poor performance reviews and such until you either leave on your own accord or they have a sufficient rear-covering paper trail to fire you.

I'd recommend that you find a place to work that will value your academic leanings. They're out there. You'll also find some that are on the fence between pragmatic and academic. A job like that may be your best option since that would allow you to invite some chaos into your approach as you help others rein theirs in.

Improve this answer
1
  • +1 @jfrankcarr for the shrewd observation of "may be given junk assignments" (a form of constructive dismissal)
    – therobyouknow
    Dec 29, 2011 at 11:39
2

Before taking such drastic measures like changing your employer, I would try to improve your own ability of explaining non-programmers like you executives why your way of coding is better for the company, and saves them time and money. And also, make sure you did not apply design patterns just for the sake of design patterns - are you sure you did also follow the rules of KISS and YAGNI? (Ok, strategy pattern and polymorphism are no rocket science, give your colleagues some time to adapt and explain them why you choose that approach.)

Improve this answer
3
  • I agree, the problem is that they don't want to learn, don't want to change their mentality (I'm not a genius in Java but when I don't understand something that majority of people consider as an excellent thing to know, I will make effort to learn it (books, internet articles, stackoverflow etc...) To sum up, they don't want to have headache with patterns (I say pattern but I could say "Excellent" principle of programmation more generally) that don't bring them much more money... It's hard to say that but it's so true. If only application was working well=> I surely would not write this topic.
    – Mik378
    Dec 29, 2011 at 8:21
  • @Mik378: you are talking a lot about what "the others do wrong". Sure that everything you did was right?
    – Doc Brown
    Dec 30, 2011 at 6:56
  • @DocBrown polymorphism has the distinct disadvantage of fragmenting the logic across files where simple instanceof's keep it in a single method. Perhaps the work units are too small?
    – user1249
    Jan 2, 2012 at 12:05
2

At my company, we conducted a series of workshops based on Clean Code Developer. The purpose was to create a forum outside of the normal day-to-day business with its hectic and deadlines and foul compromises, where developers could learn about software design principles (like you mentioned), programming techniques etc. and reflect on their projects and their own work.

Real-life examples from actual projects were discussed as well. Feedback from the participants was AFAIK very positive. It's hard to measure an actual benefit, though.

Attendance to those workshops was partly on company-sponsored time, partly the participants' own spare time. You won't reach those colleagues who don't care about learning and simply want to do their job and go home, but for anyone else who has some interest in his own work left this might be interesting.

Improve this answer
1
  • I like this idea a lot.
    – temptar
    Dec 29, 2011 at 9:16
2

I would first of all do a check that your way is really better. Object Oriented code can be very nice, but it can also be a nightmare of hidden side effects and every action can require several different classes.

Better yet go to InfoQ and Watch Rich Hickey's talk on "Simple Made Easy"

Improve this answer
1

You're going to have to give in a little if you want to keep working there without constant struggles. A dev group that is all procedural isn't going to accept polymorphism right away. Although they may not be able to design in a O-O manner, they can learn from your code. They may appreciate that some of you code is easier to maintain.

As a side note, you need to ask questions during the interview process to see what development process and coding methodology is used if you think it is important to match your preferences.

Improve this answer
0

Emergencies happen. You're not perfect and their hands will spoil your code at some point. That unless you never take time off, which, as your GP will confirm, is not good for your health. And leads to higher chances of emitting poor code.

Your code may have an higher quality, (unproven fact) but they have policies. (sure as hell fact)

You've been warned to follow policies, and will be liable of not having followed them. In an emergency situation. In a banking application. I mean, if your goal is ending poor and in jail I can figure out many funnier and more meaningful ways to get the to same result.

You cellmates, though, would be delighted to hear you rambling about the lack of curiosity of your former coworkers.

(then again, your company probably has no internal policies against OO design, but the clumsy handed COBOL-trained engineer that will try to fix your code will make some up out of thin air and, IMHO, in a worst case scenario, he'll have a 40% chance of scoring a critical hit)

Improve this answer
3
  • 1
    Personnally, I think that a real very good developper do great code as quickly that dirty code. I agree with you for the aspect of emergency ... but when a project is plannified for during 4 months, and developers don't even have a global view of what they will did, how and if something already exists in the application that will help them, I couldn't accept it. When a developer says : "I know this code is horrible but I will never refactor it because I may break it", it is ridiculous. Are they engineer or not? An engineer should take risks and make some real good unit tests to be confiant
    – Mik378
    Dec 28, 2011 at 23:56
  • 1
    I would agree if we where not talking banks here. I always feel they're a different bunch from the other programmers. They're also usually older. (In my surroundings, at the very least, as everywhere, I infer) Their math is simple, but their accuracy is not.
    – ZJR
    Dec 29, 2011 at 0:22
  • @ZJR You are getting carried away here, with your prophecies of the OP doing jail time for using OO. Most banking code is not subject to such scrutiny.
    – quant_dev
    Dec 29, 2011 at 10:46
0

Try to remember that programming is considered by some as a means to an end rather than for the sake of itself. Think of all the products and services you use: do you spend much time considering if the code underneath is made elegantly? Or do you simply appreciate them as they just work? Find an industry or cause you are passionate about, then find an organisation with that, then offer them solutions that include programming but not only that. Problems can be solved brilliantly in different ways.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.