Whatever Happened to Programming?

Discussions

News: Whatever Happened to Programming?

  1. Whatever Happened to Programming? (31 messages)

    Mike Taylor wrote two insightful essays about programming today. Are we stuck in a tedious loop of gluing APIs together? What happened to the creative aspects of programming? Check out these thought-provoking essays! Whatever happened to programming part 1 talks about how the most enjoyable part of a new project occurs early on, when things are just taking shape and the most creative effort takes place. Whatever happened to programming redux is a response to many comments he received so far, with more insightful commentary. Here is a bit more background about Mike Taylor and the kinds of things he's up to. Great posts both, and a way to go into the weekend with something to ponder.

    Threaded Messages (31)

  2. Answer (for Java): type erasure. It erased interest in Java as a 'cool' programming language. In other words, it made Java a new COBOL. And the fact that some programmers think that it's OK since COBOL developers are still payed $$$$$$ only underscores this.
  3. Wow, where to start. Let's start with 2 points. 1) Seriously, we need to steal IT/Programming away from the computer scientists. They're teaching crap that's good for "computer scientists", but basically useless for software developers, i.e. software engineers. Implementing data structures? In 20+ years, I've never implemented one in the real world. I use the one available in the programming languages. I need to know them, and their +/-, but certainly not how to implement them. Operating Systems? Grammars? Oy. 2) Programming is growing up. Talk to a real engineer. Mechanical. Electrical. Civil. Do you really think they sit around all day using calculus to solve tough problems? No, they reuse existing designs. Integrated chips. Off the shelf circuit boards. We're at that point now in IT. A good developer understands the basic theory of computing, understands the available building blocks, and knows how to wire them together to solve a problem. The key is that the tough problems of yesterday are trivial today. A word processor or a spreadsheet program was a monster. Today, they're freely available on the web. Our complex systems today require millions of lines of code, and you don't build them from scratch. In fact, if you did, one might say that you're not really a professional. Mark

  4. Mark wrote:

    1) Seriously, we need to steal IT/Programming away from the computer scientists. They're teaching crap that's good for "computer scientists", but basically useless for software developers, i.e. software engineers. Implementing data structures? In 20+ years, I've never implemented one in the real world. I use the one available in the programming languages. I need to know them, and their +/-, but certainly not how to implement them. Operating Systems? Grammars? Oy.

    I've enjoyed implementing low-level data structures in Java on several occasions where we identified that the JSE's collections data structure weren't optimized for the job at hand. Knowing how to do it was valuable in terms of time to market and fun factor.

    2) Programming is growing up. Talk to a real engineer. Mechanical. Electrical. Civil. Do you really think they sit around all day using calculus to solve tough problems? No, they reuse existing designs. Integrated chips. Off the shelf circuit boards. We're at that point now in IT. A good developer understands the basic theory of computing, understands the available building blocks, and knows how to wire them together to solve a problem.

    And yet, just wiring things around can become so boring... that's why the better Java programmers gravitate toward building frameworks, the paycheque programmers stick to using the frameworks. Building frameworks is where the fun and creative parts of Java live, not in just assembling things.

    As an engineer, I use existing stuff when it makes sense, but deeply enjoy diving into new waters when it doesn't, or when the SLA/business requirements/technology/etc. demand a different approach. That's also why we're shifting our applied research to running third-party languages in the JVM. Lots of fun in those new realms, where you can use languages with features that Java still lacks, or with more streamlined libraries than some of the bloat you find in JSE/JEE.

    Cheers!

    E
    I'm speaking about non-Java languages in mission-critical apps for the JVM at TheServerSide Java Symposium. Check it out!

  5. If you're bored wiring things together, then you're working in the wrong domain. Sure, it's probably boring wiring together the 57th shopping cart application, but there are tougher problems out there.

    "Real" programmers drift to frameworks? Puleez. Real programmers work on tough business problems that provide value to their organizations. Hacking the 23rd web application framework may be intellectually stimulating, but it's not really solving a problem.

    I guess I'm more an engineer, and less a programmer. As an engineer, I want to solve challenging *new* problems, not solve the same problem that's been solved a dozen times before, but in a slightly different way.

    Mark



  6.  

    "Real" programmers drift to frameworks? Puleez. Real programmers work on tough business problems that provide value to their organizations. Hacking the 23rd web application framework may be intellectually stimulating, but it's not really solving a problem.
    Your words, not mine -- I never said "real". I also find hacking web applications tedious, boring, and unchallenging, so we agree on that regard.

    I guess I'm more an engineer, and less a programmer. As an engineer, I want to solve challenging *new* problems, not solve the same problem that's been solved a dozen times before, but in a slightly different way.
    As a computer engineer, I couldn't agree more with you. As far as frameworks are concerned, there is more to Java frameworks than web applications. I invite you to open yourself up to other areas. I've been working in Java since 1996 and I have yet to use any web app framework myself (though I toyed with, or have built enterprise infrastructure for Wicket now and then, though I prefer Django for that kind of thing). There is plenty of work in very interesting areas where Java can be applied and far away from the web frameworks problem domains. A quick look at the JSRs will show that: OSGi (old stuff, introduced in 1998 but picking up steam in the last 2 or 3 years), Jigsaw, NoSQL, Hadoop, cloud... lots of interesting problems to solve with immediate applicability in many business domains, where the web app framework is the cherry you put on top. At least that's what my recent employers and clients think.

    Cheers!

    E
    Enterprise/cloud hybrids without the BS at TheServerSide Java Symposium. Or you can follow the discussion on Twitter.
  7. @Mark Woyna +1

    It was fun the old days but this is a new age and everything changes.
  8. I think the open source movement has become a fair antidote to academic computer science - but there is room for more.
  9. 1) Seriously, we need to steal IT/Programming away from the computer scientists. They're teaching crap that's good for "computer scientists", but basically useless for software developers, i.e. software engineers. Implementing data structures? In 20+ years, I've never implemented one in the real world. I use the one available in the programming languages. I need to know them, and their +/-, but certainly not how to implement them. Operating Systems? Grammars? Oy.

    I think the problem with over-arching statements like "...useless for software developers..." is over-simplifying and denegrating an engineering/science degree.  

    There is much more to a data structures class then just "how" they are implemented.  There is also training in code efficiency and the mathematical proofs involved in determining, without a shadow of a doubt, the efficiency of any algorithm you implement, whether or not that includes a data structure.

    Furthermore, understanding a data structure's efficiency helps you to better understand how efficient your algorithm will be.  

    In terms of the use of "Calculus" and other science that software eningeering and computer science graduates use academically, I argue, is applicable to every project a software engineer gets.

    Calculus, physics, etc. all teach critical thinking skills.  And if you want to argue which is harder and/or which involves more application of critical thinking, physics or learning APIs, you'd be hard pressed to argue in favor of learning APIs.  

    If you were to argue the former, then we can both agree that learning via computer engineering or computer science courses is not useless to a "software developer" and can only stimulate a project's intelligent approach to implementation. 
  10. But come on[ Go to top ]

    So programming is not fun if you're not working with bits and bytes? We all know there are different levels of programming. A good programmer is creative and can create something new using reusable components. It's just architecture on another level.
  11. I think that the key to enjoyable programming is working at the correct level of abstraction, so that every line of code has the appropriate amount of meaning.

    Often you'll hear about a framework or library that lets you "focus" on the business logic. You'll also hear people talk about getting rid of incidental complexity. These things are all working towards the same thing. It may be cliche but it's an excellent and difficult goal to achieve. The interesting thing that took me a while to realize is that the "business logic" can be a huge range of things. This is why I laugh when people talk about any tool or language in any kind of absolutes. Is memory management part of the business logic of a web application? Probably not. But sometimes the meat of your code IS bit twiddling and managing memory. Sometimes your business logic makes the most sense in assembly! Business doesn't have to be enterprisey business related code. Its just the non-incidental complexity.

    Given that - relating back to what Mike was saying, there are two things going on:

    1. Managing incidental complexity
    2. What kind of genuine complexity do you want to be programming?



    The first issue is present at every level. If you haven't been able to do it well, you will enjoy programming less, and you will be doing a lot more copy/paste coding and you will feel like a lot of your time is spent shoveling code around or writing plumbing code. I think this is where that feeling of new gets lost. Unless you are in full maintenance mode adding no new features, as your application grows, it starts to bloat and rot and feel gross to live in because the signal to noise ratio is really low. Everything you do you feel like you've done before because in many cases you have, you just didn't make it very reusable.

    The second issue is obviously more subjective, but I think it is also a big part of the "modern programmers aren't real programmers". There is a lot of genuine complexity (read business logic) that isn't exactly computer science, and doesn't stretch the minds of people who yearn to become better programmers. Can you collapse most e-commerce sites down to the same thing done over and over? In many ways - yes. And in the areas that really are the same, that is where a library or framework is key to getting down to the core of things that really are different. The parts that are different may not be interesting - effectively just the website design/layout, but there is something there.

    Personally, I find one of the most interesting areas of development the act of making genuine complexity my incidental complexity. In other words, creating ways of removing incidental complexity. This can be a very challenging problem, ranging from language design, to development tools, etc. Including it as part of my development process means that I'm always working on a new challenge. Either I've gotten rid of my incidental complexity and I'm working on the business code of the application at hand, or I'm working on getting rid of the incidental complexity. Its not always possible to do, but it keeps me enjoying my job.
  12. What kind of genuine complexity do you want to be programming? This is a good question. An electrical engineer I knew used to tell the story of the cake mix. These came out after WW2 he said..and included powdered eggs. Homemakers did not buy them..they wanted to be more a part of the process. Thus: Out went the powdered eggs in went the note "beat two eggs, add." He saw this as the problem for engineers as useful tools were subsumed in framework .. he saw it as natural trend..but said the tool makers had to remember to leave stuff in there for developers to do...
  13. Today's programing is just glue things together, and there is not creativities?
    The objective of software is glue hardwares together, in the first place, right?
    But thanks to software, the computer is not only device to compute scientific caluculations, but also to use in general purposes, say, for bussiness, play, communications.

    Today's programing is just glue things together, and there is not creativities?
    In these days, we programmer have some knowledge about OS, GUI components, DB or Transaction Middleware, Internet protocols, XML or other text-base-format's parser, scripting languages and its GC, Interoperabilities with other programming languages, i18n and l10n, concurrent and threading ( especially today, in multi-core-cpu environment ), construction of devices in computer and network, and so many things.
    And these components has own objectives and significances.
    If you don't understand whole-and-part, you can't achive functional requirements.

    Today's programing is just glue things together, and there is not creativities?
    The only you need is how to use these parts?
    You don't need to know about its internal design or implementation?
    Really?
    It must be certainly not.
    To reuse software components in right way and effectively, we have to know about ideal design, actual design, current implementation, old implementation, bugs, limitations that comes from its design and implementation and also its organization and people who are created, and also know about asumming normal situation that this softwares are used or at least they were (i.e. historical backgrounds, current trends ), ... etc.
    If you are not skilled enough, you can't achive requirements of performance and quality.
    Actually, I don't believe the software without source code can be reusable.

    Today's programing is just glue things together, and there is not creativities?
    Absolutely not.
    Only God ( omniscience and omnipotence ) can do.
    Or imposter might do.
    If you are gonig to be in eigher way, don't you think it is very creative and challenging job?
  14. The Agile Software Developer[ Go to top ]

    Some days ago I've written down some thoughts about the developer in agile projects and how it changed the skills needed.
  15. I agree the posts above that there are different levels of abstraction in programming and that writing data structures and the like might be fun but are increasingly unnecessary (in general.)

    But I also agree with the main sentiment of the original post.  Programming seems to be a dying art, especially in the enterprise world.  The thing is that people are still doing programming if you buy into my idea that the essence of programming is translating processes into instructions that the machine can process.

    The problem I see is that because there's an idea that 'programming' is an old way of doing things, people are building systems without knowing the fundamentals.  I've seen extremely expensive, unreliable and non-reusable systems implemented to avoid writing one straightforward Java class at 1/10 the cost.  The only reason for doing this was to avoid having any code.

    Those who know how to develop need to be careful about what we do with these skills.  If we spend a lot of time writing low-level stuff that adds no value, we will only add to the belief that programming is not needed.  We need to make sure we are using our skills to show how 'programming' is often the best possible choice.
  16. Success Happened[ Go to top ]

    The graybeards who look back longingly over the history of programming and what it used to be vs what it is today have missed a pretty critical aspect. The amount of programmers/programming happening right now is thousands of times greater than it used to be. Society has changed. Computers won! We are now much more reliant on them than we ever were for so much that happens in our lives. There is a lot of code to write, but that doesn't mean its all great, and it doesn't have to be great.

    I think an excellent analogy here would be restaurants. Those succeeded too. And guess what - there are a lot more fast food joints and pizza/sandwich places than fine cuisine. And while a great chef may enjoy looking down on McDonalds and the pimply teenagers that barely know how to use a fryalator, the fact is that there is clearly a need and it fills that gap.

    The problem is that cooking has been around a lot longer than programming, and programmers (as well as programming tasks) get lumped together too much. Programming needs to be celebrated as a craft that takes a lot of skill and experience to master. We need turn-key solutions and wysiwyg the same way that we need microwave dinners. But just because you can use a microwave, doesn't mean you're a chef.

    If you yearn to be a chef, don't work at McDonald's. Same goes for programming. It is not a dying art. If anything, I think it is getting stronger all the time. You just can't look at the enterprise to find it.
  17. Success Happened[ Go to top ]

    If anything, I think it is getting stronger all the time. You just can't look at the enterprise to find it.

    That's merely a popular misconception.  And no amount of rhetoric will change that.  There is more development going on in enterprise than anywhere else.  Part of the reason people think otherwise is that they arbitrarily decide certain things are not programming when they really are.

    For example, when I started my current job, one of the managers was convinced that he had eliminated 'code' by using a graphical ETL tool.  I wrote a quick stylesheet and dumped 1000's of lines of 'expressions' from a single table mapping.  When you look at the tool you can't see that buried inside little modal dialog boxes that there are all kinds of statements hand-typed into every mapping.  When we looked at the whole set of these expressions, it was clear we had more code than we ever had before.  It was just less visible, less maintainable, less reusable, and more expensive to build.

    Anytime that you are describing a process to a computer that it will execute, you are programming.  Whether you write it as words, symbols or draw pictures is irrelevant.  If we can get past the arbitrary semantic distinction, we can have rational discussions about the best tool for the job.  Right now many billions of dollars are wasted by forcing people to use inadequate tools in order to avoid 'programming'.  This approach is somewhat like trying to operate a automobile from the passenger seat in order to avoid driving.
  18. You misunderstand me[ Go to top ]

    I was not saying that you will find less programming in the enterprise, far from it. I was saying that you should not look to the enterprise for GOOD programming, or people who care about programming as a craft. In my analogy, a large amount of enterprise and web programming is McDonald's and microwave dinners. Its still programming, its just not what people like you and me and Mike Taylor want to do.

    That said, the existence of fast food does not mean four star restaurants don't exist or are in decline. I think you will find that the volume of great programmers is higher than ever, its just that the percentage of great programmers/programming jobs is lower than ever. The same is probably true about chefs if you included every McDonald's employee and line cook.
  19. Success Happened[ Go to top ]

    If we can get past the arbitrary semantic distinction, we can have rational discussions about the best tool for the job.  Right now many billions of dollars are wasted by forcing people to use inadequate tools in order to avoid 'programming'.
    I think you and I are really on exactly the same page when it comes to how we want to program. I am a total programming language geek, and abhor wysiwyg/drag and drop tools. Aside from certain things such as graphics which may result in code (such as svg), if it cannot be expressed easily in code, someone did a bad job somewhere along the lines SOAP.

    Personally, I believe that smaller teams of better programmers is far more productive than larger teams of worse programmers. That is also why I work for small companies. Should enterprises follow suit? Probably. Might put a lot of people out of work though ;) And quite honestly, it goes a little bit back to interest. A lot of corporate developers have less skill and would not want to work on the kind of code that I enjoy. And for me, even if I got to use the tools and language that I would prefer, I still would not enjoy the programming problems that they have to tackle. I don't want to sound elitist, but spinning up a ton of small sites, e-commerce apps, or generating reports and forms is just not that interesting to me, but going back to me previous comment, there is some genuine complexity there that has to be coded, even if it could be done incredibly succinctly.

    Just as there is a market for fast food that is low quality, but cheap and good enough, there is a market for coding that is low quality, but cheap and good enough. I could complain because it waters down the craft, but I'm pragmatic and just avoid fast food. And besides, it gives the small companies I work with an advantage.

  20. Success Happened[ Go to top ]

    If we can get past the arbitrary semantic distinction, we can have rational discussions about the best tool for the job.  Right now many billions of dollars are wasted by forcing people to use inadequate tools in order to avoid 'programming'.
    I think you and I are really on exactly the same page when it comes to how we want to program. I am a total programming language geek, and abhor wysiwyg/drag and drop tools. Aside from certain things such as graphics which may result in code (such as svg), if it cannot be expressed easily in code, someone did a bad job somewhere along the lines <cough>SOAP</cough>.
    Sorry for misinterpreting your comment.  I think, though, that you may still be misunderstanding what I am saying.

    I don't dislike using WYSIWYG tools or box-and-arrow tools.  I'm actually a visual-spatial person and tend to prefer diagrams.  But there are many many problems in IT/enterprise development where a text-based programming/query/transformation language is simply a far superior solution.  Try to teach someone how to balance a checkbook using only pictures (no words allowed).  Now consider that balancing a checkbook is about 10,000 times simpler that the kinds of processes we automate where I work.  It's not about my personal tastes.  It's about building correct, robust solutions at minimum expense.

    All though my career (which spans over a decade) I've been told that we should use tool X because it's easier.  The problem is that just because a tool is simpler to use doesn't mean it will be easier to solve a given problem with it.  To give an analogy (I love analogies) a shovel is easier to use than a back-hoe.  But contractors this heavy equipment instead of the obviously simpler tool.  They must be so stupid!  Or maybe, just maybe, instead of making facile deductions based on flawed logic, they use the tools that allow them to get the job done quickly at least expense.

    Basically, I'm trying to get the job done using the tools that will allow for a high-quality solution to be developed at minimum cost.  Having managers and other people pushing inadequate garbage down my teams throat is not helping.  It's hurting.  It's second biggest cause of project failures (e.g. late delivery, low-quality) that I deal with on a regular basis following a lack of well-defined requirements.
  21. Success Happened[ Go to top ]

    @James Watson: Right now many billions of dollars are wasted by forcing people to use inadequate tools in order to avoid 'programming'.

    Can you give us some name? :)

  22. Success Happened[ Go to top ]

    @James Watson: Right now many billions of dollars are wasted by forcing people to use
    inadequate tools in order to avoid 'programming'.


    Can you give us some name? :)
    Pick a company.  There's s 99% chance they are wasting money in this way.  It should be obvious that I'm pulling these numbers out of my ass.  I think they are fair estimates.  Perhaps you need a disclaimer.

    Dislaimer: I pulled these estimates out of my ass.
  23. Success Happened[ Go to top ]

    I was asking about inadequate tools"
  24. Success Happened[ Go to top ]

    I was asking about inadequate tools"

    Oh, sorry.  Are you familiar with Informatica or Visual Basic?  There are others that are more relevant but I don't want to start a flam war about a specific tool.  Especially without making the following qualification first.

    Most of the tools I am referring to, including the above, are useful for certain problem domains and often have clear benefits in terms of speed of delivery and supportability.  However, they generally are limited in scope.  If you need to solve a problem that fits entirely within the scope of the tool, you should use it if it's a better choice.  However, I have rarely had a problem which did not have at least some part of it that fell outside of the scope of the tools capabilities.  In that situation, you have a few choices including: restructure the problem to fit the tool (this usually significantly increases the size of the problem), use more than one tool to solve the problem, or try to force a solution with the wrong tool.

    In this context, any tool can be inadequate.  I think Java is inadequate for a number of problems and for a larger number it's not a very efficient choice.  But I think that's a lesser problem than trying to make people build things with tools that lack the appropriate features.

    To give a concrete example, Informatica is an ETL mapping tool.  So you draw little lines connecting boxes here and there.  For a certain type of problem, it's OK.  But what you gain in ease of use you lose much more in endless repetitive manual work.  For example, in order to trim an input field, you have to map a field to an expression, node, then open a tiny dialog and type "ltrim(rtrim(field))".  If you have 100 fields to trim, you have to open 100 little dialogs and put the "ltrim(rtrim(field))".  Of course you could copy paste but then you run a greater risk of getting the field name wrong.  If you have 10's of thousands of fields that need to be trimmed (like we do), guess how many times you have to do this?  In Java, I built a reusable solution that will trim all the strings from a database row one time (plus allowing for a lot of other things like this).  It probably took me as much time as it takes to do the Informatica approach for 50 fields.
  25. Success Happened[ Go to top ]


    Oh, sorry.  Are you familiar with Informatica or Visual Basic? 
    The problem with tools like Informatica is that to do anything out side the tool is difficult (or was last time i cared to look).  About 5 years ago I ran into this issue in DTS. The good news was that you can export the dts and modify it in VB (VB was better than nothing :( ).  Anyway, we had a DTS process that had multiple duplicate processes. So I exported, [manually] refactored the code so i could make my changes once in tool designed to code instead of 4 times in a postage  stamp window.

    Tooling like this is not bad if you can "write code" when you need to.  For instance Websphere Message Broker and BIRT. While these are not perfect, i can code when i need to and when it is not easier to draw it. 

    I have seen the opposite happen when people hand code things when it would be easier to draw it or configure it.  And even worse, they are doing copy and paste coding.
  26. today is better[ Go to top ]

    Call me weird, but I actually think things are getting better pretty much every year. 

    Compared to say two decades ago, you can today realistically (meaning not just a few coding gods) build systems that are more flexible, powerful, you name it and actually deliver them and see them in use. It is acceptable nowadays that you use the best language/ framework/ os/ (no)db solution for the job, and it seems that people finally gave up on 4GL and other horrible ideas that were considered hot back then and focus on better languages, APIs and tooling to support coding.

    I for one like it that you start closer to the problem you're trying to solve, and that those problems can be much more ambitious and sophisticated because of that. To me the fun in programming is the creative part of coming up with the appropriate abstractions, data structures, algorithms, and the fact that you can fill some of the building blocks in doesn't make it any less creative to me.

  27. today is better[ Go to top ]

    Call me weird, but I actually think things are getting better pretty much every year. 

    Compared to say two decades ago, you can today realistically (meaning not just a few coding gods) build systems that are more flexible, powerful, you name it and actually deliver them and see them in use. It is acceptable nowadays that you use the best language/ framework/ os/ (no)db solution for the job, and it seems that people finally gave up on 4GL and other horrible ideas that were considered hot back then and focus on better languages, APIs and tooling to support coding.
    I absolutely agree with you.  Wicket is an excellent example of a framework that puts power into the hands of the developer ;)  Unfortunately, in my experience, management (at large) has not caught up with this.  There is still an obsession with COTS and 4GL in many organizations (on a side note, I think this is the root cause of bloated IT budgets given these tools are expensive for what they give you.)

    The other side of the problem is that people think that unless you are building custom linked-lists or red-black trees, that you aren't really programming.  If someone feels that way, they really need to look at the problems that can be addressed at a higher-level.  These are often more challenging and satisfying and the solutions have much greater value than low-level algorithm and data-structure work.
  28. today is better[ Go to top ]

    I think that both aspects are equally important to achieve the final goal of all development - i.e solving a business problem. It is equally satisfying to glue API's together of readymade frameworks/tools as it is to develop and implement a complex algorithm - as long as the solution is used to solve a business problem.

    Of course, I have seen other factors in play (read "sales") where solution architects have put in complex COTS products with cumbersome integration effort to solve a problem which could have been done by custom programming in a simple, efficient and cost-effective manner.

  29. today is better[ Go to top ]

    Of course, I have seen other factors in play (read "sales") where solution architects have put in complex COTS products with cumbersome integration effort to solve a problem which could have been done by custom programming in a simple, efficient and cost-effective manner.

    Absolutely.  I see it all the time.  I've worked with a number of people (usually the ones making the decisions) who believe it is almost always cheaper and better to buy software than to build it.  While it is often the case that it's cheaper to buy (i.e. universal or common need tools e.g. spreadsheet), the assumption that it is always true means that the analysis doesn't happen.  Many other times it's best to build or use a hybrid solution.  The hybrid solution would be optimal in the vast majority of the cases I see except that most vendors don't make any effort to support it.  When I ask our vendors about adding very simple features that would make it easier to use their tool in our ecosystem, I get a bunch of questions about why I wouldn't want them to do everything for us which is a symptom of a common delusion with software vendors that can provide everything we need at the level of quality we require.
  30. I work in an organization that states "We are buy versus build". And other than a few work-group type apps, all the "enterprise" apps (but one) are bought.  But we still have tons of "programmers". Because the purchase apps need to be customized and integrated. Sadly, almost every one of the bought apps was not designed to do these things.  And most of the developers don't have the proper tooling.  Most of the vendors are not small players. They create large applications for the Medical Industry.
  31. I work in an organization that states "We are buy versus build". And other than a few work-group type apps, all the "enterprise" apps (but one) are bought.  But we still have tons of "programmers". Because the purchase apps need to be customized and integrated. Sadly, almost every one of the bought apps was not designed to do these things.  And most of the developers don't have the proper tooling.  Most of the vendors are not small players. They create large applications for the Medical Industry.
    I'm in a very similar situation and it sounds like we are in the same (or at least related) industry.  What I find so ironic about this is that the logic is that it's cheaper and better to buy yet are costs are out-of-control and the quality is much lower than in other places I have worked that built more of their software internally.

    Sometimes, I think this attitude is more about control than about the stated goals.  When applications are built internally, it's apparent the developers have a lot of power in the organization.  Buying software takes away some of this power.  The thing that most organizations fail to realize is that it puts that power in the hands of the vendor and that the vendor isn't as accountable to the organization as it's own developers.  I've seen again and again that vendors will sometimes decide that it's not worth their effort to support the customer.  I've even seen cases where our vendors have been purchased by our direct competitors which puts us in a pretty sticky situation e.g. the vendor refuses to implement what we need at any price.

    From a business strategy perspective, this it's pretty stupid to buy software without careful consideration but the conventional wisdom says otherwise.
  32. Not only does it reduce our "power" it reduces the "gene pool".  And the overall developer gene pool is bad enough. Don't get me wrong. There are plenty of smart people at these kinds of places. But they never seem to have "grown up". "Why isn't HL7 and TCP/IP good enough? That is what everyone does."

    IT should not be "in control". But it shouldn't be controlled 100% by the Business. In the industry i am (currently) in, we have many highly educated people. They don't understand that that doesn't qualify them to understand technology and thus make decisions. Heck smart people who have been in IT all their lives are just automatically qualified.