Richard Bair explains why "Not Invented Here" isn't bad

Discussions

News: Richard Bair explains why "Not Invented Here" isn't bad

  1. Richard Bair, in a blog entry titled "Not Invented Here," has explained why he thinks that writing your own framework or tool might be justifiable, even when an alternative (such as an open source project) exists for the same purpose.
    The problem with developing API's that rely on some third party project is that if the third party project decides to grow in a different direction, or modify components or APIs in a way that doess't harmonize with your own APIs, you end up having a huge mess. You end up having to fork their project (assuming that their project has a license compatible with your own). Even if they are doing fine but you have bugfixes/feature requests that go unanswered, you have to fork the project. Or when their release schedule is incompatible with your own, you end up delaying your own product or forking theirs.

    This problem doesn't usually occur as an application developer, or even developing massive APIs that are internal to an organization, but happens when you are developing APIs for the general community.
    What do you think about projects that duplicate capabilities found in other packages?

    Threaded Messages (54)

  2. Well at least for api usage I suggest to not reinvent the wheel but to write thin wrappers around. This is most useful if you only need a small subset of features of the api. I think it wouldn't make much sense to write your own wrapper for the swing api.

    You should choose to use non intrusive Frameworks like spring. Spring or othe DI Frameworks can also be used to reduce coupling to other projects.

    Conclusion: Use existing Projects. Don't reinvent the wheel. If the used Projects move into a different direction as you whish, be prepared to replace them in a smooth way (wrappers and/or Dependency Incection).
  3. My +1 for Bastian.

    I think it could be reasonable to write your own framework if it's more in synch with your application's business needs, but it's plain stupid to write, say, your own database connection pool or xml parser (yes, I have even seen that....). I usually make a distinction between "commoditized" components and buisiness-logic related ones.
  4. but it's plain stupid to write, say, your own database connection pool or xml parser (yes, I have even seen that....).

    I would say it is much more stupid to say that.
    There are always circumstances that building your own stuff is
    more pragmatic and with greater ROI then using existing stuff.
    And you can be supprised a lot that it is the case much more than you could imagine!

    For example, I still haven't found a decent open source connection pool with the features, performance, scalability and reliability of mu own connection pool (first version written in year 2000, when no production ready open source pools even existed).

    Jakarta commons pool, for example, locks the whole pool while one connection is being allocating from the database! You cannot return other connection to the pool, or borrow one that is idle as the whole pool is locked! And allocating connection can last seconds! Also, rare are the pools that have maximum connection live time parameter that tells the pool to close the connection after it is being allocated for, say, 1 hour. Having long lived connections (a day or more) is the Bad Thing (tm), as all sort of leaks and nasty bugs caused by network glitches are more probable to occur when connection live so long.

    Saying that writing custom XML parsers is stupid is also unwise. There are situations and requirements when this is really needed. In one project we needed a really small Java 1.1 compatible XML parser to be embedded in an applet. Even Aelfred was too big (and also had nasty bugs) that writing custom XML parser was the only solution.

    So, never say never in software development. Take the pragmatic approach, wherever it leads!
  5. A Controller Servlet and one Session Bean: This is all what you need. An extra component such as DisplayTag or Apache commons' can make your task a bit easier.
    Faisal A
    B'ham,UK
  6. Abstraction[ Go to top ]

    Isn't this the exact reason you abstract away much of your core logic away from interacting with these services? Shouldn't one use data manipulations data access objects, data movement around in primatives, JRE provided objects and data transfer objects for returning data? Controller specifics should not be so tightly coupled, that you can't switch frameworks.

    Lose the heavy dependency on stuff and make your code work, even in simple unit tests.
  7. This problem doesn't usually occur as an application developer, or even developing massive APIs that are internal to an organization, but happens when you are developing APIs for the general community.

    Uhhh...no... API changes are huge problems for application developers. It's true that NIH in application development usually isn't motivated by API instability, but API instability certainly generates HUGE costs for application development projects. Which means it should be a consideration for application development projects.

    Rolling your own solutions that could come from third-party libraries/frameworks can be a legitimate decision. But NIH is not a valid reason to roll your own library.

    What Richard Blair is really saying is that rolling your own library/framework is a valid approach to reducing the risk associated with introducing external dependencies. I think that's absolutely correct, but it shouldn't be confused with NIH.
  8. Reinvent the wheel?[ Go to top ]

    Good reasons to reinvent the wheel:
    1. A custom wheel design will give you a strategic or tactical advantage.
    2. The added value of a custom wheel is greater than the cost of developing one, or off-the-shelf wheels cost a lot of money.
    3. Your reliance on a potentially unstable supplier of a critical wheel would unacceptably jeopardize your project.
    4. You can invent a wheel that suits your needs quicker than evaluating all the other wheels, reading thousands of pages of wheel documentation, and adjusting your design to match the selected wheel.

    Bad reasons to reinvent the wheel:
    1. You didn't know someone already invented it.
    2. You assume your wheel is bound to be better because you're the one inventing it.
    3. You have a fascination with wheels and have always wanted to invent one.
    4. You just don't like using other people's stuff.
  9. Reinvent the wheel?[ Go to top ]

    +1
  10. Reinvent the wheel?[ Go to top ]

    Wow, talk about wrapping up the essence in a small amount of space. Is there anything left to argue?
  11. Reinvent the wheel?[ Go to top ]

    Agree.

    Another bad reason to reinvent the wheel:

    You can blame the external tools/libraries for the failure of your project. Otherwise, you have to take all blames for your OWN codes!

    In case you are the one choosing the tools/libraries, you would still be blamed for the bad choice, but it is a LESS severe blame, especially if that tools/libraries are (1) from a large famous vendor; (2) known to be used by many people; (3) comforming to standards.
  12. Reinvent the wheel?[ Go to top ]

    +1!
  13. Inventing is educational[ Go to top ]

    +1 to Richard. Having been through several framework-building excercises in one role or another I can confirm that especially for developing teams inventing the wheel is the best thing you can do. The thing is that layering tons of libraries on top of each other without actually knowing why or how they were desined is a Bad Thing (tm). If you start building you own components, however, you have to think about issues you would otherwise ignore. Even if you discover that someone out there has developed a better solution for your problem you can probably point out _why_ theirs is better and in case of multiple possibilities make an educated choice.
  14. Inventing is educational[ Go to top ]

    I agree. It has been my experience as well that certain open source initiatives try to be everything to everyone in order to gain wide acceptance. Sometimes, a small quick homegrown solution is a better one. After all, many of the open source projects we all have grown to appreciate started as small projects targeting a specific business problem. my 2 cents
  15. Best of both worlds[ Go to top ]

    The idea that a team should write everything from scratch is silly. I think that's pretty well-known. OS projects that are sed by thousands of teams are going to have a lot less bugs and other problems that one written and used by a single team. I know that from experience.

    But, on the other hand, it is a risk to couple code to an API that you don't have control over. But this doesn't mean you need to code from scratch. You can develop an abstraction layer that fits the needs of your application and then implement it with one or more third-party APIs.

    For example, we have a logging API that was developed in-house. At thiss point, the whole thing is using Log4J. But there's nothing in the API that ties us to Log4J. If we need to change to a different logging tool or support more than one, it's easily done without refactoring large swaths of code. This is smart. Developing your own logging tool is not. We have that too. It's not good.
  16. Best of both worlds[ Go to top ]

    For example, we have a logging API that was developed in-house. At thiss point, the whole thing is using Log4J. But there's nothing in the API that ties us to Log4J. If we need to change to a different logging tool or support more than one, it's easily done without refactoring large swaths of code.

    Can Spring do this? That is, not insist on a logging facilty? I haven't found how to disable this !@#%!@$@#^ feature. Why, oh why, does Spring insist on having a logger to do anything. It is mind-boggling stupid!

    Other than that Spring is pretty good;-)
  17. Best of both worlds[ Go to top ]

    Can Spring do this? That is, not insist on a logging facilty? I haven't found how to disable this !@#%!@$@#^ feature. Why, oh why, does Spring insist on having a logger to do anything. It is mind-boggling stupid!Other than that Spring is pretty good;-)

    What exactly are you referring to? Spring's own use of Commons Logging? Well, the framework needs to write into some log, mainly for tracing and debugging purposes. We use Commons Logging for that, which should nicely log to the console by default - unless you have log4j.jar on the classpath. There shouldn't be any need for special setup.

    Spring is no different to other popular libraries in that respect: Hibernate, Struts, WebWork, Quartz, etc all use Commons Logging for their internal logging needs. This means that the choice of the actual logging backend can be configured centrally for all those frameworks, as they all go through the same logging abstraction.

    Juergen
  18. Best of both worlds[ Go to top ]

    Well, the framework needs to write into some log, mainly for tracing and debugging purposes.

    This is what I don't get. I should be able to use Spring without any tie-in to any logging facility. I should be able to use Spring and not have to include any logging library in my classpath or anywhere else. Spring should happily do its thing totally and not log a thing anywhere if I don't tell it to...or if I tell it not to. I may have log4j.jar in my classpath for something totally separate.
    Hibernate does the same thing. If you have Log4j.jar in your classpath for general logging, then you want to use Hibernate configuration gets out of whack....
  19. Best of both worlds[ Go to top ]

    Well, the framework needs to write into some log, mainly for tracing and debugging purposes.
    This is what I don't get. I should be able to use Spring without any tie-in to any logging facility. I should be able to use Spring and not have to include any logging library in my classpath or anywhere else. Spring should happily do its thing totally and not log a thing anywhere if I don't tell it to...or if I tell it not to. I may have log4j.jar in my classpath for something totally separate. Hibernate does the same thing. If you have Log4j.jar in your classpath for general logging, then you want to use Hibernate configuration gets out of whack....

    So TURN IT OFF! What exactly is the problem? I have one entry in a property file that turns off Spring's logging?
  20. Best of both worlds[ Go to top ]

    So TURN IT OFF! What exactly is the problem?
    How? I've got 2 books (Pro Spring, Spring in Action) and have scoured several Spring sites and I don't see how. Pretty please with sugar on top can you show me how to disable it?
  21. The thing is that layering tons of libraries on top of each other without actually knowing why or how they were desined is a Bad Thing (tm).

    It is not that hard to determine what a library is doing. Are you saying that you can recreate the functionality of framework faster then figuring out what it's libraries are doing?

    I love it when people at work try to re-invent frameworks from the ground up. It brings humor to the workplace, and gives the rest of us something to laugh about over drinks.

    One company a good friend of mine worked at tried to build their own ORM. After two years they never got the bugs worked out, and it's cross database support was terrible, and it caching was weak leading to performance problems. In their case there was no reason not to use Hibernate.

    My wife works at a company where the lead developer has convinced the IT manager that they need to build their own MVC framework. The project is a joke, he spends all his time braging about features he is adding that already exist in other MVC frameworks. They are now 2 months late on starting their next project because everyone is trying to get this framework done.

    I know of too many shameful example to list here....

    If you are working on your own, and for the sake of learning you want to recreate an existing framework, then more power to you. I have been working on an XSLServlet for the last year on my own time. Why? because I can, and it has been a great learning expirence.

    If you are on company time, and you don't *need* to build your own framework. Save your company a buck, get over your small penis syndrome, and get on with your project.
  22. A problem I see (non-technical) is that those (managers) who have pumped large amounts of money into developing the frameworks are not so keen on having their grand plans deprecated for alternative products.

    Technical merits do not always drive business decisions (at least at big companies where there's money to burn).
  23. Please read the post carefully, it was about developing teams just getting started. I'm talking about people who first saw Java 2 months ago and who refer to Thinking in Java on a regular basis. Of course, a seasoned developer is better off picking carefully frameworks they can use and developing the rest. However, _becoming_ a seasoned developer while still being able to deliver production-strength code is a different matter. This thread could probably go on forever, so let's just cut it by saying that (who would have guessed?) you should make informed choices and think before adding a jar to the classpath.
  24. (who would have guessed?) you should make informed choices and think before adding a jar to the classpath.

    I agree with you here.

    Please read the post carefully, it was about developing teams just getting started. I'm talking about people who first saw Java 2 months ago and who refer to Thinking in Java on a regular basis. Of course, a seasoned developer is better off picking carefully frameworks they can use and developing the rest. However, _becoming_ a seasoned developer while still being able to deliver production-strength code is a different matter.

    I must be misreading this. Are you saying that entry level java developer are better of starting out by developing their own frameworks? If you are talking about a university setting, where they are writing code purly for the sake of learning, then I might agree with you. BUT if you are talking about entry level developers working for a company, that needs to produce a production product, then I 100% fully disagree with you.

    How many people here have learned java by developing their own Struts, Spring, or Hibernate framework?? I would guess that most people started by learning the mainstream frameworks first, then as their Java skill increased they were able to determine when things should be done in house vs off the shelf.
  25. How many people here have learned java by developing their own Struts, Spring, or Hibernate framework?? I would guess that most people started by learning the mainstream frameworks first, then as their Java skill increased they were able to determine when things should be done in house vs off the shelf.

    Apparently, the original contractors that wrote the system I maintain were learning while writing it. That includes a couple frameworks. And that's why my job sucks.
  26. My wife works at a company where the lead developer has convinced the IT manager that they need to build their own MVC framework. The project is a joke, he spends all his time braging about features he is adding that already exist in other MVC frameworks.

    Another war-story here:
    A "bright mind" (of a third company) reinvented EJB + MVC. A critical project is implemented on top of that framework for a very big car company.
    The only NIH-components are the JDK and Log4J:
    - there's no developer-documentation. Not. A. Single. Line.
    - the database-description (tables, attributes, references, queries) is in XML. 1MB of XML.
    - the workflow is defined in XML. but it goes far beyond such things as struts or JSF: he even reimplemented language elements like IF,SWITCH-statements and comparisons into XML! There are serveral variable scopes which interact by voodoo magic (need I to say: no source code of the framework available...). They're defined by obscure characters.
    - I repeat: No documentation.

    A nightmare.

    Now I'm in the position to bugfix this monster. The customer is always grumbling why even small fixes and features take so much time... Millions of Euros sunk into a pit...

    That's not my first encounter of such frameworks from "bright minds" - technicians whose ego make them ignorant of such profane things as usability, documentation and maintainability.
    They start with the (sometimes even really good) vision of a new wheel but lose interest at a point when the wheel "somehow" starts to rotate but is in no way capable of supporting a car someone likes to drive day by day.

    I haven't seen a "guru" who has BOTH the vision and the endurance to bring such a thing to a state of true project-maturity.
  27. let me guess...[ Go to top ]

    ...this is a framework by a German company.

    You want documentation? You gotta PAY for that!
  28. Inventing is educational[ Go to top ]

    If you start building you own components, however, you have to think about issues you would otherwise ignore.

    Last time I checked, the purpose of frameworks, libraries, and abstraction in general was to enable people to ignore issues they would otherwise have to address.
    The thing is that layering tons of libraries on top of each other without actually knowing why or how they were desined is a Bad Thing (tm).

    To what depth? There's a big gap between knowing the general theory and design for something, and having the knowledge to actually build it from scratch. I'll agree that using a library without knowing the basics of the theory behind it and its design is a Bad Thing. But the purpose of using a library is so that you only need to know enough of the details to successfully use it.

    I'll agree that building a framework or library can be a tremendously educational experience. Back in school, I had a class on databases where we had to write a "simple" RDBMS in C++. It was hard. It was painful. It was immensely educational. But an employer would be wasting its money to pay a developer to sit at work writing a RDBMS just so he knows the gory details of how one works. Writing off-the-shelf components for the experience is something that should be done as part of an educational experience, formal or informal, not as part of a job.
  29. A similar entry at JoelOnSoftware offering a slightly different perspective that you may find interesting:

    http://www.joelonsoftware.com/articles/fog0000000007.html
  30. Read this quote carefully:
    First, let me state that I am in favor of leveraging existing work whenever possible. It is often more economical to purchase tools than to build your own. It is sometimes more economical to purchase tools than use open source equivilents. It is sometimes wiser to use open source implementations than either purchasing or writing your own. Each circumstance and situation is different, there isn't one right answer for every situation.

    Also, the opinions expressed below are from an API designer's perspective, not from an application developer's perspective. Some of the same principles can be applied, but it should be noted that an application developer's needs and goals are fundamentally different from those of an API designer.

    Note that he's talking about API developers NOT application developers. Personally, I despise the NIH philosophy as I've found that 95% of the time it's a complete waste of time and often a huge mistake. However, writing and API is a completely different animal. Unfortunately, I think a lot of devs will read this and think that they need to setup a logging system or whatever for their project and that this advice somehow applies to him. It doesn't. You are not an API developer just because your project needs a logger.

    And to the developer that wrapped log4j. Why? Please explain this decision. What is it in log4j that made you think this was necessary? There are some valid reasons for doing this and I'm curious what yours was.
  31. And to the developer that wrapped log4j. Why? Please explain this decision. What is it in log4j that made you think this was necessary? There are some valid reasons for doing this and I'm curious what yours was.

    I didn't do it. A team at my company did. The reason being that they did not want to couple every Java class in the organization to a single third-party tool.

    Whether this is actually necessary in this case, I have my own doubts. But the end result is that I have everything I need for debugging and it works perfectly. If we needed, for some reason to remove Log4J from our libraries, it could be done without changing a single line of the application code.
  32. The reason being that they did not want to couple every Java class in the organization to a single third-party tool.

    This, I would say, is not a good reason to wrap log4j. If for some reason they had to change to a different logger (in house or otherwise), it can be done extrememly quickly with a quality IDE. So all the wrapping is doing is enhancing the performance drain of the logging. So the net benefit is zero with a cost of poorer performance.
  33. The reason being that they did not want to couple every Java class in the organization to a single third-party tool.
    This, I would say, is not a good reason to wrap log4j. If for some reason they had to change to a different logger (in house or otherwise), it can be done extrememly quickly with a quality IDE. So all the wrapping is doing is enhancing the performance drain of the logging. So the net benefit is zero with a cost of poorer performance.

    Enhancing the performance drain?

    Changing tens or hundreds of projects, containing perhaps thousands or tens of thousands of classes, using a "quality IDE"?

    Are you joking? If you are not, then I bet you have never been on a project with more than ten people all in all.
  34. Refactoring is not a panacea[ Go to top ]

    The reason being that they did not want to couple every Java class in the organization to a single third-party tool.
    This, I would say, is not a good reason to wrap log4j. If for some reason they had to change to a different logger (in house or otherwise), it can be done extrememly quickly with a quality IDE. So all the wrapping is doing is enhancing the performance drain of the logging. So the net benefit is zero with a cost of poorer performance.

    This is a specious argument. If the new component has a fundamentally different API structure, it may not be a matter of just replacing method names. This is similar to an argument I once saw saying that you should put Swing/AWT code in your data Objects and allow them to render themselves. The reasoning being that Swing and AWT are already abstractions. Yes, they are, but this means very little if you want to move the application to struts or JSF.

    Regardless of all that, the company I work for employs hundreds of developers, some full-time and many contractors. Going though hundreds of lines of code and refactoring mission-critical (revenue generating) code and changing it is extremely costly and risky. Even in the case of the completely deficient logging framework that was home grown and used in a lot of the code I work with, we can at least tear out the internals and make it an adapter to the new improved framework.

    The 'poorer performance' point is also completely off-base. Logging is generally slow. Adding a hin wrapper over Log4J makes no appreciable difference in performance.
  35. your next job[ Go to top ]

    Think about your next job...

    For developers, skills in well known frameworks are portable. These are skills you can take to another position if you get layed off or decide your current job sucks.

    For managers, using well known frameworks makes it much easier to bring new people on. Good luck finding a developer that can hit the ground running with your home grown framework.
  36. Think about your current job...[ Go to top ]

    How many people do you know that try to insure their "job security" by being the only ones who know how such-and-such piece of code works, or how to configure such-and-such application? How many managers do you know that push people to do this because they want to have one go-to guy for problems with a certain application or module?

    I've met plenty.
  37. your next job[ Go to top ]

    Think about your next job... For developers, skills in well known frameworks are portable. These are skills you can take to another position if you get layed off or decide your current job sucks.
    For managers, using well known frameworks makes it much easier to bring new people on. Good luck finding a developer that can hit the ground running with your home grown framework.

    Unfortunately, I find that this attitude is too prevalent in our industry. Do we want to be treated as mere cogs, unable to do any thinking on our own? Why would we, as programmers, encourage others to perceieve us as mere technicians? Imagine the interview: "Your programming credentials are impressive, Mr. Gosling, but you lack the necessary knowledge of Struts..."
  38. your next job[ Go to top ]

    Think about your next job... For developers, skills in well known frameworks are portable. These are skills you can take to another position if you get layed off or decide your current job sucks. For managers, using well known frameworks makes it much easier to bring new people on. Good luck finding a developer that can hit the ground running with your home grown framework.
    Unfortunately, I find that this attitude is too prevalent in our industry. Do we want to be treated as mere cogs, unable to do any thinking on our own? Why would we, as programmers, encourage others to perceieve us as mere technicians? Imagine the interview: "Your programming credentials are impressive, Mr. Gosling, but you lack the necessary knowledge of Struts..."

    You CAN build a framework on top of say Struts, Spring, and Hibernate. I had a company court me pretty hard because I demostrated that I COULD create a framework backed by basically standard components. I didn't accept because I enjoy my current position.

    Take another example where the customer wants to take over maintainance after the project delivers. The document that I have to produce is basically how I use Struts, Spring, and Hibernate. As soon as the question about how to configure AOP or add a new table comes up, I just have to point to the Spring or Hibernate book.
  39. your next job[ Go to top ]

    You CAN build a framework on top of say Struts, Spring, and Hibernate.

    Never suggested that you couldn't. My point is that you choose those frameworks for a reason, and the reason wasn't just "because I know these frameworks."

    Which would you rather have build your house, a carpenter, or a hammer operator?
  40. monkey at a keyboard[ Go to top ]

    I find that this attitude that "because I'm a programmer, I'm indispensable" too prevalent in our industry. In fact, IMHO this hubris is more damaging than the perception of being a "technician".

    Most of us are merely application developers; we build applications for internal or external consumption. We are hired to implement features, integrate systems, or maintain legacy code. We are high paid monkeys, and nothing more. No matter what magic you've created, how much of a system you understand, or what amazing framework you've developed; you are replaceable. Someone else might do a worse job, but they'll do the job adequately enough. The sooner you realize this, the happier you'll be, and the more you'll be prepared for the layoff when it comes.

    http://www.newtechusa.com/ppi/talent.asp
  41. monkey at a keyboard[ Go to top ]

    I find that this attitude that "because I'm a programmer, I'm indispensable" too prevalent in our industry. In fact, IMHO this hubris is more damaging than the perception of being a "technician".Most of us are merely application developers; we build applications for internal or external consumption. We are hired to implement features, integrate systems, or maintain legacy code. We are high paid monkeys, and nothing more. No matter what magic you've created, how much of a system you understand, or what amazing framework you've developed; you are replaceable. Someone else might do a worse job, but they'll do the job adequately enough. The sooner you realize this, the happier you'll be, and the more you'll be prepared for the layoff when it comes.http://www.newtechusa.com/ppi/talent.asp

    To some degree I agree with you. On the other hand, I've just witnessed the cancelling of a $2 million project with no working deliverable. There are inadequate developers/designers. My personal feeling is the unwillingness to pay and the inablilty to recongnize good developers and designers is the main cause of software project failure and poor results.
  42. monkey at a keyboard[ Go to top ]

    I find that this attitude that "because I'm a programmer, I'm indispensable"...

    Can you elaborate? Why does solving a problem using the most appropriate framework, or with custom code, instead of mindlessly reaching for framework X, make you a megalomaniac? I don't see the connection.
  43. monkey at a keyboard[ Go to top ]

    We are high paid monkeys
    Who are you calling a monkey? I hope I don't ever have to fling poo at you! :)
    Someone else might do a worse job, but they'll do the job adequately enough.
    Maybe they will do it adequately. Maybe they won't.
    The sooner you realize this, the happier you'll be, and the more you'll be prepared for the layoff when it comes.
    It wouldn't make me happier. If fact, I feel sadder right now.


    Instead of repeating what has already been said ...
    http://www.jroller.com/page/cpurdy?entry=joel_s_semi_annual_post
  44. monkey at a keyboard[ Go to top ]

    I find that this attitude that "because I'm a programmer, I'm indispensable" too prevalent in our industry.

    In fact, IMHO this hubris is more damaging than ..

    I was just having a very similar conversation yesterday, so I was glad to see the way you put it here. I think too often we (software people) forget why it is that we have jobs, which is very simply to make other people's lives easier. We can be very good at that (computers and software _can_ make people's lives easier) but it's still no reason to get an "I'm indispensable" attitude.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  45. monkey at a keyboard[ Go to top ]

    I find that this attitude that "because I'm a programmer, I'm indispensable" too prevalent in our industry.In fact, IMHO this hubris is more damaging than ..
    I was just having a very similar conversation yesterday, so I was glad to see the way you put it here. I think too often we (software people) forget why it is that we have jobs, which is very simply to make other people's lives easier. We can be very good at that (computers and software _can_ make people's lives easier) but it's still no reason to get an "I'm indispensable" attitude.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    great reply, you're indespensible. :^)
  46. monkey at a keyboard[ Go to top ]

    I find that this attitude that "because I'm a programmer, I'm indispensable" too prevalent in our industry.In fact, IMHO this hubris is more damaging than ..
    I was just having a very similar conversation yesterday, so I was glad to see the way you put it here. I think too often we (software people) forget why it is that we have jobs, which is very simply to make other people's lives easier. We can be very good at that (computers and software _can_ make people's lives easier) but it's still no reason to get an "I'm indispensable" attitude.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java
    great reply, you're <correct spelling>indispensable.</correct spelling> :^)
  47. monkey at a keyboard[ Go to top ]

    ...We are high paid monkeys, and nothing more.

    Speak for yourself Monkeyboy. There is a huge difference in the quality of developers and the quality of their work. On every team I have ever been on, I deliver the highest quality code, I deliver it faster, therefore am much more productive and my code is very easy to understand and maintain. There is a HUGE difference!

    Good luck Monkeyboy - sounds like you'll need it.
  48. "Monkey Boy" is one of most competent developers I've ever known. You may not agree with him, but he speaks humbly about the profession because he has an excellent grasp of what's going on in the field. Things seem like this to him because of his competence on the matter. Someone incompetent would never say these things! The point made is not about whether developers have valueless skills but about the skill set not being unique. He's right. Many see themselves as the panacea of knowledge in this field. I can't stand talking to those people and I avoid them like plague. Even non-programmers often claim excessive knowledge and can dole out ridiculous criticism. Software testers and project managers come to mind here. I hope to never reach a level of hubris that isolates me from the people I serve. Maybe you are more competent than anyone else but I can tell you that I would rather work with "Monkey Boy" than an arrogant $%^&. Taking pride in the profession is one thing, condescension is quite another.
  49. It depends...[ Go to top ]

    Developers should use established frameworks whenever possible UNLESS you are a GREAT developer like me. My DAO framework beats the hell out of Hibernate, Firestorm or any of that other crap that's out there.
  50. It depends...[ Go to top ]

    <joke>
    I would love to pay you top $$$ to buy your DAO framework. hey, better still, I would love to pay you $$$ to build me a new DAO framework that is better than your DAO framework.
    </joke>

    For PRODUCT development teams, you should roll your own framework if:

    - you are addressing core aspects of your product's architecture
    - your "ilities" need (performability, scalability, manageability) is so stringent that you need a deliberately skewed architecture where using someone else's "generic" framework will not help.
  51. Excuses[ Go to top ]

    These reasons are just technical excuses to reinvent the wheel. The true reaon is that companies don't want to depend on an open source entity that may, at some time be controlled. Thru sponsorisation, for example. And it is possible that their competitors try to gain such control on that open source entity (foundation or whatever) and my deliberatly dictate a bad direction for further development.

    I worked with IBM and noticed that they even write their own XML parser. They simply won't depend on sources that may become unreliable at some point. The same strategy is adobted by most companies and the reasons are 100% not technical.
  52. As of I know most of the companies who invented their peristence, MVC and other framework got fialed or they scrapped the project.
  53. As of I know most of the companies who invented their own peristence, MVC and other framework got fialed or they scrapped the project for some other reasons.
  54. Building a custom framework or API isn't always a bad thing. Actually, I get tired of seeing people "check out" when they hear that (gasp) something was actually built "in house".

    IMHO the key to whether a "custom" offering is relevant or not depends on what you are trying to accomplish with it. If you're trying to build something that replaces a "well tested", "widely understood by the development community at large", "everybody already knows how to use it and it does a pretty good job" piece of technology with something of your own then you should probably check your motives for doing so. However, if nothing really exists that elegantly handles the problem you are trying to tackle, have at it ... make it better.

    I think that custom software has taken its lumps because the people that write "frameworks" or APIs don't think that they will ever be replaced - so they make them very closed and rigid. On the other hand, however, software shouldn't necessarily be replaced just because it was written in house either. If it works, it works well and the maintenance costs aren't horrendous ... leave it alone!

    I've seen some really elegant frameworks and APIs that have been written in house that are much better than ones that have become "standard". Yep, I've seen some stinkers too.

    The key needs to be (and I think this is one of the things that separates a developer from a really great developer) the ability to recognize when to use something from the community or shrinkwrapped pool and when to "roll your own".

    Don't bill your customer/employer to write something just because you think it would be fun, make sure that it provides real value that you can't get somewhere else.

    One thing to remember is that every, now standard, framework or API was at one time someone's "homegrown" solution.

    -Adam
  55. awareness[ Go to top ]

    we're app/product developers (vs. api) working in a vertical that requires attorneys to fully understand all the terminology and entity relationships. despite the challenges that provides for the tech side of things, there are a number of home-grown infrastructure frameworks in use here: mvc, persistence, pooling.

    i'd like to see oss alternatives used more often, but it is not a slam dunk. unlike some other shops i've seen with poorly done home-grown stuff, these in-house solutions are pretty good. the time spent to build them could have been invested elsewhere. the frameworks are now in use, so that design/build time is gone, but time does get spent to improve/fix things.

    does a line need to be drawn saying that, "ok, we've messed with this thing long enough?" fortunately, these home-grown items are done well enough and the development staff is good enough that there is no extreme pressure to do so.

    we recently had a need for a scheduler. work began on a home-grown cron parser. we quickly found quartz, saving weeks of work/debugging. i think the issue is not one of NIH (but it could play a part), but rather one where the guys don't know what they don't know. <- key point

    i'm just as guilty. a friend had asked me about current goings-on and said, "check out quartz". it was a lesson for me to first look for existing wheels and spend the time needed to evaluate them to make sure they provide what is needed rather than try to invent one.