Discussions

News: Yakov Fain defends hacked-up code -- opinions?

  1. Yakov Fain says some provocative and interesting things in an interview (http://java.sun.com/developer/technicalArticles/Interviews/community/yakov_qa_2010.html) on java.sun.com. For example:

    "Recently, I've been running a seminar for a small group of Java developers. Several times they've asked me, 'Is this code an example of MVC pattern?' I got the impression that implementing MVC had become an end in itself. Using Design Patterns is not a dogma. Just write the code that makes sense. Not everything that makes sense has a named design pattern."

    "Abusing design patterns is not always the fault of Java developers. I find the approach used in the enterprise software shops similar to medicine in the US. In my opinion, lots of doctors here practice 'protective medicine.' They are trying to protect themselves from malpractice law suits. Enterprise managers and tech leads also try to minimize the risk introduced by lower-skilled developers who are part of every team. Yes, abiding to object-oriented principles definitely helps in making code readable, but this does not always translate into better performing applications. If hacked-up code produces great results, apply it without worrying whether another developer will have problems understanding it."

    Question: When is this good advice and when is it bad? More often than not, I think we should worry about whether another developer will have problems understanding it, but maybe I'm being too cautious and conservative. 




    Edited by: staff on Apr 1, 2010 11:42 AM

    Edited by: jvaughan on Apr 1, 2010 11:50 AM

    Edited by: jvaughan on Apr 1, 2010 11:51 AM Edited by: staff on Apr 1, 2010 11:55 AM

    Threaded Messages (29)

  2. Never know about replying on Apr. 1st. lol

    Anyway, working code is the most valuable asset, period. Any half-ass developer can rework and refactor working code into something more flexible and more maintainable.

    It's all based on need. Usually for a business, time to market with the right features are the two most important factors. Customer's care about using it now so long as it does what they need it to do. They just don't care that you used an MVC or other patterns, and why should they? More importantly, why should you if they don't?

    It took me a few years to learn this concept. There's a time and place for patterns and clean code, but that usually isn't at the forefront of application development. It's better suited for libraries, tools, frameworks, and other types of broad-reaching code.

    I've seen horrible crap code I've had to clean up, yes, but I still maintain, if you can't get it working by the time you need to (or agreed to), then you are headed for the hurt locker.
  3. very naieve[ Go to top ]

    The notion that working code is the most valuable is the naieve attitude of either a beginner or a pointy-haired-boss. Not just naieve but dangerous.

    First of all, "working" is hard to define. The people with this attitude usually think "works on my machine" is enough.

    Here's reality: all non-trivial code that was important enough to get "working" once, will need maintainence.

    Yes, always.

    And the next guy (who might be you) will take your name in vain (or worse) if all you did was hack something quick that appeared to work so you could tell your PHB it was done and make your spring or kloc quota for the week.

    Then the grownups will eventually have to clean up your mess.


    I say this as one who has spent several decades having to deal with code written by amateurs with this naieve attitude.

    For the PHB's out there: it will always cost more, and not just in the long run, to get it right, to fix the flaws, etc.


    Btw, yakov is wrong too (as usual).
  4. There are far too many architects who spend valuable project time 'over-architecting'. Too much is attempted and, as the original poster suggested, the architect/developer is focused more on building the perfect software beast rather than meeting the business objective in the necessary time frame. Over-architecting can do just as much damage to a project as a novice programmer if not restrained.

    Design patterns, MVC, etc. are good things and I'm not suggesting creating something that is not maintainable but you've always got to balance this against delivering something that works and will help your business today. Usually, this results in a good, but not great, piece of software and that's how it should be.

    That's my 2 cents.

  5. There are far too many architects who spend valuable project time 'over-architecting'. Too much is attempted and, as the original poster suggested, the architect/developer is focused more on building the perfect software beast rather than meeting the business objective in the necessary time frame. Over-architecting can do just as much damage to a project as a novice programmer if not restrained.

    Amen!
  6. Value of Architecture[ Go to top ]

    There are far too many architects who spend valuable project time 'over-architecting'. Too much is attempted and, as the original poster suggested, the architect/developer is focused more on building the perfect software beast rather than meeting the business objective in the necessary time frame. Over-architecting can do just as much damage to a project as a novice programmer if not restrained.

    Design patterns, MVC, etc. are good things and I'm not suggesting creating something that is not maintainable but you've always got to balance this against delivering something that works and will help your business today. Usually, this results in a good, but not great, piece of software and that's how it should be.

    That's my 2 cents.


    OK, I will agree that a fair number of people with "architect" in their title do too much of what they call "architecture" and end up with over-architected solutions.

    I'll also accept that in a lot of cases, no real architecture is even required.

    That said, if you're building something to last, and something that will have to change and grow over time, then you have to start with good architecture. And if you don't have good architecture, then basically nothing else matters, because the end result will be failure.

    I'd suggest that we not disregard architecture just because too many poor architectures originate from people with "architect" in their titles ..

    Peace,

    Cameron Purdy | Oracle Coherence
    http://coherence.oracle.com/
  7. Value of Architecture[ Go to top ]

    Cameron,

    On a slightly personal note, it was great to see Oracle's active participation in and sponsorship of TSSJS 2010. I thought it was a nice touch to have James Gosling speak in the keynote. I did not get a chance to attend your session, but I am sure it was very good.

    Cheers,
    Reza
  8. I'm not sure if I agree with Fain or not.

    In my last 5 years of coding in Java, I have never once had a situation where I absolutely needed to write 'hacked-up' code to make it faster.  If you find yourself in this situation, it would suggest to me that there is fundamental lack of understanding of how to make use of abstractions.  Generally, in order to improve performance, I need to improve my abstractions and possibly add more.  Eliminating abstractions to improve performance is something I only would do under deadline pressure and I consider it to be the result of a design error.

    Though this wasn't really referred to in the interview, we need to be clear on the difference between easily readable code and easily understandable code.  Readable code (good formatting, good naming, following conventions, etc.) is not optional.  There is no excuse for writing unreadable code.  Understandable code is something else entirely.  I have suffered under leadership who believe that if there's a single developer on the planet that doesn't understand my code, I should rewrite it to make it simpler.  The flaw is that just because something is easier to understand doesn't make it easier to enhance and maintain.  It's often the case that the simpler the design, the harder it is to deal with.  This is a big source of where software complexity comes in.  I find myself frequently debating this point to people who want to eliminate parts of my designs to simplify things.  The thing is that though the complexity has a cost, it often has a lot of value such as increasing reliability and allowing for recovery from catastrophic failures.

    Perhaps this is what Fain means but his statement is a little unclear.
  9. HA![ Go to top ]

    Interesting to see how the new website handles these insertion attempts. I'm curious how it bypassed the captcha though.
  10. I personally thing the following statement is a little extreme "If hacked-up code produces great results, apply it without worrying whether another developer will have problems understanding it".

    There are cases in which 'hacked-up code' is acceptable, but you really need to consider the context of the code, the importance of that logic to the system, and so forth.

    Enterprise 'focused' companies due suffer from Design Pattern abuse and complex designs. Engineers need to understand that the term 'enterprise' isn't defined by complexity or heavy usage of design patterns.

    Over the years, we've been drifting away from this into lightweight and simple designs. e.g., Moving away from EJBs, etc.

    Starting today, I encourage every engineer to take part in "Slap the shit out of morons" Friday. If a developer says or does any of the following:

    1. says "That's not a best practice" or "It's a best practice"
    2. Measures quality of code based upon number of Design Patterns used
    3. Abuses XML
    5. Abuses Annotations
    6. Uses acronyms when speaking with managers or during meetings.
    7. Acts like an Enterprise whore

    Enjoy slapping until your hands get sore.
  11. Over the years, we've been drifting away from this into lightweight and simple designs. e.g., Moving away from EJBs, etc.

    Nice attempt at a troll.

    If anything we're moving TO EJB to reduce the complexity of manually handling transactions and persistence contexts. EJBs are much more lightweight than the typical spaghetti code people write.

    We also have a game btw. It's not slap the moron on Friday, but it's kick the idiot on Monday. Someone who is attempting to spread mindless FUD like EJBs are heavyweight or JSF has failed is tied with their hands to the ceiling and used as a good old kicking bag. Oh, and I've been in kick boxing for nearly a decade so believe me, I know how to throw a decent kick.

    If you fancy a new job, please come work with us. We could use the extra exercise. 
  12. This posting has trolling or ignorance written all over it. I won't spend much time feeding into this, but I will say the following on the subject matter.

    When the EJB specification first came out, it was a complete mess and it was fact heavy weight. To enlighten you on this, let's look at some leftover artifacts. Ever wonder where the following J2EE design patterns came from and why?

    Data Transfer Object (DTO)
    Session Facade 

    Let me help encourage you to think about this a little more. Why are frameworks like Spring and Hibernate very popular? Why have they changed how frameworks are designed?

    There's no need to pretend to be a hard ass online. Stick to the subject matter and if you're looking to throw a little pun (Hence the slap the shit out of morons comment) into the conversation, feel free, but don't be a dick about it and address it to someone.

    Enjoy your day.
  13. When the EJB specification first came out, it was a complete mess and it was fact heavy weight.

    News flash: It's 2010 now, not 1999 anymore. Even EJB 2.1 is almost 7 years ago (late 2003). Stop pretending like it's 1999 forever. Things do change you know.

    EJB 3.0 is a very lean, lightweight and powerful technology. EJB 3.1 is even better.

  14. News flash: It's 2010 now, not 2005 anymore. EJB technology proved to be inefficient and JSF proved to be a bad model for web-based development. Oh, and enterprise softwares went purely web-driven. 

    Perhaps EJB is still in the message-oriented middleware part, but most of the time, different technologies are used.

    JSF also makes your life harder: anyone who uses JSF essentially proves that he does not wish to understand web technologies deeply. It simply does not map well for the underlying technology - making a lot of abilities hard to reach - and does not map well for the model it wanted to provide - GUI-based applications.

    So, get an XHTML/CSS book, perhaps start learn some modern framework like grails or ror or django, you could even start to learn PHP - after all, it proved to be scalable, driving most of the world's most popular and dynamic websites like facebook, farmville, flickr, just to name a few.

    Yet saying that hacked-up code is good is of course, beyond any rationale. Just make sure you know what you're doing and the patterns will be inevitable - not necessary to name them.
  15. Adam,

    Do yourself a big favor and take a look at how people are effectively using Java EE 5 with Facelets/Seam as well as what CDI, JSF 2 and Java EE 6 offer. If not seeing what Spring/Hibernate offer is a sign of ignorance, I would say failing to acknowledge the results that Java EE adopters are seeing in real life is not a sign of great wisdom either, not to mention the very large number of projects that use JSF with Spring and Hibernate pretty effectively.

    Now, it might be possible that you personally prefer a request centric presentation tier model (e.g. Struts) rather than a component centric one (e.g. JSF, Wicket) or that you like the explicit configuration model or framework model of Spring better than the platform, strong defaulting model that Java EE/CDI/EJB 3 offers, but that's a different statement than making the types of statements you are making. If you insist on them, please provide specifics of what you mean with code examples and let's discuss it by all means...

    Cheers,
    Reza

    P.S.: Comparing RoR, PHP to Spring, Java EE is very silly. These technologies in truth solve very different problem domains, while it is true they can adopt ideas from each other (Java EE certainly adopts many ideas from RoR). Resin has a native PHP interpreter and Resin is heavily used in many PHP shops. We would never suggest that these users look to Java EE and vice-versa specifically because the problem domains are so different that such a suggestion would be very meaningless.
  16. yeah,

    whose idea was to introduce EJB lite to web profile.

    Is there another web profile that does not include EJB. My only problem is that, if you give user crap, they will find a way to include crap.
  17. There is no Java EE Profile that does not include a version of EJB since EJB is the mechanism to deliver container services such as transactions and security. There is no Profile without JSF for similar reasons.

    The broad consensus based on Java EE adopter and/or implementer feedback is that there is no good technical reason for such a Profile. If you believe there is, I am happy to hear good, solid technical reasons that are properly researched and thought-out and does not regurgitate pseudo-techninal, outdated FUD that is really not defensible and fairly easily dealt with.

    If you do not wish to use EJB 3.1 or JSF and still insist on using a Java EE compatible application server, you can easily do so. After all, there are plently of JBoss, Resin, GlassFish, WebSphere, WebLogic users that do so for good technical reasons primarily related to performance and stability while continuing their use of Spring, Hibernate, Struts, Wicket, etc. I beg to differ that most developers worth worrying about are that naive to use an API without serious considertaion in this day and age. I personally do not run into any such users that often.

    Cheers,
    Reza
  18. Guys,

    *With all due respect*, let's please, please leave this alone - it is a tangent here at best. Most people that have spend a non-trivial amount of time looking at Java EE 5 or Java EE 6 don't have much trouble understanding where things are at the moment. For most developers/architects/managers, it's pretty clear what the evolution for the past decade or so have been. For those who still don't it's just a matter of looking around a bit and having an open mind (characteristics most engineers have)...

    Cheers,
    Reza
  19. I've known Yakov personally for a few years and have always looked up to him as a veteran Java champion (I've certainly benefited from his counsel a number of times).

    That being said, it is not too far out of character for Yakov to overstate a point. I doubt Yakov really defends hacked code that usually is a clear indicator to poor professional conduct. I think he is merely trying to state that not every piece of code in a system needs to or can always follow a design pattern. Generally, this is the kind of thing that a code review (or architecture review at a higher level) is supposed to ferret out.

    Cheers,
    Reza
    ---------------------------------
    Resin EJB 3.1 Lite Container Lead
    Expert Group Member, Java EE 6 and EJB 3.1
    Author, EJB 3 in Action
  20. If the hack gets you to market and never requires maintenance or understanding - it's golden.  

    I took a drawing class years ago that taught me a great lesson about coding.  I started out drawing every aspect of a subject in great detail trying to be an "over-architected" Flemish master.  The instructor showed us how to use the fewest lines possible to get the idea across and no more. Look at drawings by Durer vs. Tiepolo. Same goes for code.  

    My solution is to do both - hack with patterns in mind to make code decoupled and cohesive.  If you don't understand patterns, tiering, and service orientation then hacking is bad.  If you have HttpServletRequests and JDBC connections in the same method or say JSP page I would raise an eyebrow. IOC and TDD help. 

    I am working on a project that has been hacked for 5+ years where time-to-market is the primary driver.  It has caught up to the group in "stabilization" projects, in increased support needs, and increased development LOEs.  Still refactoring is discouraged.  There has to be some balance - pay now or pay later.
  21. Andrew,

    I think this is great insight and I often tend to do the same myself. The keys to succeeding in this, is of course being "aware" of the eventual patterns, having a decent test suite, continuous refactoring and avoiding perfectionism. In reality I think the "never requires maintenance" case is extremely rare outside of maybe throw-away prototypes. In fact, I've come across the case only twice in nearly a decade...

    I think the code as art parallel is very appropriate too. Like good art, learning to write good code needs time, practice, patience, vision, peer review and occasional guidance (even if simply by inspecting the work of good coders).

    Cheers,
    Reza
  22. Nice analogy Andrew, brings to mind an Einstein Quote that's particularly apt to architectures I think: Make everything as simple as possible but no simpler.
  23. Yakov is on to something that's very important... Blind allegiance to dogma is never a good thing.

    Unless the MVC abstraction makes sense in terms of the application that you are developing, you should not use it.  MVC came about in reaction to an observation that this pattern was seen in a large number of applications - a large number - not all.  MVC is a hammer, but you don't need a hammer when you are using screws.
  24. As a very experienced developer (doing OO and writing frameworks for 15 years now) it's hard if not impossible for me to develop/code an application without thinking in architecture and patterns and doing some ongoing refactoring automatically. This leads to understandable and maintainable code and good design. This is the value that my experience brings and this is why I am called software architect. If someone needs a fire-and-forget-software in no time - ok, but don't call me! ;-)
  25. Having been called in to work on a very large enterprise web app that was "hacked together" for a client by a Java developer fresh out of university I'd thoroughly recommend sticking to the MVC for web apps.

    This application was a 'dogs breakfast' to work on. Without the discipline of MVC he had embedded crucial business logic in the user interface - and where multiple user interface artifacts required the same business logic he just resorted to the 'copy/paste' pattern - which lead to a disastrous piece of crap that he walked away from and refused to do any more work on! Yes, believe it or not he no longer wanted to work on a greenfield project that was all his own making.

    Sure, he got something together that 'barely' worked but 3 years later the customer ditched it anyway because it was thoroughly worthless. You'd fix a bug only to find that the same code was copied/pasted in 4 different places and so have the "same" bug appear again and again. In the end I needed to get real good at pattern matching to find 'similar' code whenever I fixed a bug - instead of having that code in one place and being called from multiple places.
  26. This application was a 'dogs breakfast' to work on. Without the discipline of MVC he had embedded crucial business logic in the user interface - and where multiple user interface artifacts required the same business logic he just resorted to the 'copy/paste' pattern - which lead to a disastrous piece of crap that he walked away from and refused to do any more work on! Yes, believe it or not he no longer wanted to work on a greenfield project that was all his own making.
    It's not a greenfield project once it's built ;)  I've lived through this and I think it's pretty common.  What's really bad is when you have someone like this working as a contractor/consultant.  They just go from company to company scattering turds.
  27. Chris, I know exactly what you mean. It's unbelievable how many people are out there producing such a mess. Over the years I got more and more rigorous in my opinion that it is mostly a bad, bad thing to work on someone others code - especially if he/she had such a "different" understanding of the job.
    Don't take me too literally now, I just try to make a analogy: What would a master of his art, Picasso for example, say if you would ask him to complete or change a drawing that a totally non-talented rookie painted?
  28. Totally agree[ Go to top ]

    I've seen Sr Devs/Team Leads in the place I work that introduce patterns like no tomorrow.  I understand that they are trying to regulate the quality of the code to some extent especially amongst the junior developers.

    But to me that is not solving the problem.  They will never learn to solve problems, adapt and improvise efficiently, rather just trying to find existing solutions and churn out disastrous code when a problem hits them without any apparent existing pattern that fit.

    I'd rather have juniors learn how to properly interface their design by analyzing what they are trying to solve, instead of trying to figure what existing pattern works to throw at a particular piece of problem. 
  29. Not everything has a name[ Go to top ]

    Right now in software industry there is a trend:tremendous use of design patterns, an overwhelming desire to name everything that it's coded according to some standards(in this case design pattern std).

    Here it is a problem, although the things are sometimes complicate we tend to complicate them even more, when we are thinking what design pattern to use and not think the solution in our way of thinking according to the situation we are in. To me as a developer has a great importance what my constraints are and if one constraint is to name properly every section of code according to design pattern that was used or to think this as a design pattern that is known, then what it is my role in this, where it is my creation?

    For me, not everything need to be named, I don't like to precious in words but rather in code.....

  30. Every drug can become a poison...[ Go to top ]

    ... if overused or wrongly used. The ideal encounter to patterns is: "Oh, I used this for years but know I have a name for it."
    It's difficult to teach newbies the use of patterns as long as they haven't learned their lessions through own experience. Patterns should not be something artificially imposed on developers. Patterns are a big help in speaking the same language in a team of developers.