Career Question



  • @CPound said:

    RyuO,

    I noticed in your profile you mention "Agile Methods". Hasn't this been referred to as "Cowboy Coding"?

    Should someone who is new to the programming world consider this methodology?


    There is a whole bunch of "agile methods" which have relatively little in common, except for the principles as written in the "agile manifesto".
    BTW, "cowboy coding" means the absence of any method, agile or not.



  • @CPound said:

    RyuO,

    I noticed in your profile you mention "Agile Methods". Hasn't this been referred to as "Cowboy Coding"?

    Should someone who is new to the programming world consider this methodology?


    Not to start a "religious" war around here or anything, but I think the methodology one applies should be highly dependent on the project & organization.  In other words, there is no one universal methodology that will be ideal for all projects and organizations.  Some projects are best implemented using agile methods due to the uncertainty in requirements whether it be lack of internal understanding of business processes or shifting markets.  For other projects, the classic waterfall is more appropriate because the requirements are likely to be stable.  I would recommend researching various methodologies and comparing their advantages/disadvantages.  It might also be valuable to start looking into CMMI.



  • @DrPizza said:

    Don't bother.  Better money to be made in accounting, better long-term prospects too.

    Click this link.

    http://money.cnn.com/magazines/moneymag/bestjobs/

    Thank you.

     



  • @CPound said:

    RyuO,

    I noticed in your profile you mention "Agile Methods". Hasn't this been referred to as "Cowboy Coding"?

    Should someone who is new to the programming world consider this methodology?

    Excellent questions (good responses too), and thanks for asking questions I have good answers to.
    • Agile methods are about teamwork, discpline, and accountability. Programmers who can't handle those things don't stick on Agile projects, or (rarely) they coopt them. Cowboys prefer total chaos.
    • Agile methods sacrifice structure to get the other things. Therefore you code in bite-sized (measurable!) chunks, usually a month. Within that month you are highly organized, only what you produce is little paperwork and lots of working code.
    • Amazing history #1: the original and most persistent software project method is Waterfall, which had its ultimate ancestor in the Polaris submarine project in the early 50s. Polaris popularized the methods now embodied in Microsoft Project, work breakdown structures and PMI. Well, the Polaris method was a fraud! Polaris was as chaotic as the average software project, but consultants wrote a revisionist history of the project crediting its success to Gantt charts and whatnot. Subsequent generations of consultants built an entire project management method around a false premise, and little good it did them.
    • Amazing history #2: Most of the great hardware projects of the 20th century, like the SPAD, the T34 and the aforementioned Polaris, evolved into something very like Agile projects. If Joseph Stalin wants results, you tend to discard fluff. Afterwards, the engineers tended not to disclose their methods so as not to look bad to other engineers. Finally the secret got out in the Lockheed Skunkworks project:
    • http://www.astech-engineering.com/systems/avionics/aircraft/skunkworks.html
    Why mention this to a new person?
    • To be a complete software developer you need to understand the technology and the methods. In the real world, though, you get paid for the technology, so that has to be your priority. Most projects in the real world are either faux Waterfall or total chaos, so you'll probably land on one. Learning some form of software method is probably something you'll have to do on your own. It takes years to master one, so start now.
    • Start with an Agile method, because:
    1. They are the wave of the future. They actually work, so they'll be adopted more and more by shops that have to have results. At the very least, in 10 years projects will pretend to be Agile in the same way projects now pretend to be Waterfall or Spiral.
    2. They are easy to implement on small projects compared to process-heavy projects where the managers who should be protecting the developers are instead asking them what percent complete they are.
    Here are the tough questions:

    How come Agile projects don't have a better track record than any other method?
    Leaving aside the possibilities of a selection bias or rigging the results, the most likely possibility is that they are not really Agile projects. Years ago I took over an Extreme Programming project that had lost its way, and could not get it back on track because:
    • The deadlines and deliverables were driven by market pressure. XP requires that developers work to an achievable goal, but if the people paying you give you direct order to do something insane, you do it.
    • XP requires unit testing as you go, and once we stopped doing it, we could never get the time back to make it up.
    The project really failed, but the company's literature calls it both a success and an Agile project. It was really a Cowboy project, which explains why many people confuse the two.

    What don't you get from Agile methods?
    System architecture. That's something of a generalization, but the scope of Agile methods is a bunch of people working towards a common goal, and system architecture is one person with a vision bringing an amorphous collection of concepts into describable form. Integrating the two forms has been a problem for the Agile community, who mostly descend from piecework developers like GUI specialists. Not to name names, but if you look at a modern book on system architecture, it'll tell you how to build components like a model-view controller, not systems like a just-in-time inventory.

    <font face="Verdana">A great book on these topics is Balancing Agility and Discipline: A Guide for the Perplexed, by Boehm and Turner.</font>



  • @lpope187 said:

    @CPound said:
    RyuO,

    I noticed in your profile you mention "Agile Methods". Hasn't this been referred to as "Cowboy Coding"?

    Should someone who is new to the programming world consider this methodology?


    Not to start a "religious" war around here or anything, but I think the methodology one applies should be highly dependent on the project & organization.  In other words, there is no one universal methodology that will be ideal for all projects and organizations.  Some projects are best implemented using agile methods due to the uncertainty in requirements whether it be lack of internal understanding of business processes or shifting markets.  For other projects, the classic waterfall is more appropriate because the requirements are likely to be stable.  I would recommend researching various methodologies and comparing their advantages/disadvantages.  It might also be valuable to start looking into CMMI.

    Sensible comments, but how many of us have seen stable enough requirements for Waterfall to work? I've seen maybe one, but it was a fluke where the mission was to produce a workalike of a legacy system for a different platform. Somehow or other, that project went over the waterfall in a barrel too.

    CMM is good but, at least up to level 3, it is about repeatable process, not necessarily good process. I was, in fact, at a company in the final throes of their CMM Level 3 certification, and you would not believe how much stupid but repeatable stuff was in their process.

    You can also game the certification auditors; in the company I was talking about people only had to repeat their processes until they got through the audits, and within a week reverted from stupid but repeatable to just plain crazy.

    CMI also has a Personal Software Process, which certainly helped me in my early days. Highly recommended, but PSP is a lot to take in for a beginner.



  • @RyuO said:


    Sensible comments, but how many of us have seen stable enough requirements for Waterfall to work? I've seen maybe one, but it was a fluke where the mission was to produce a workalike of a legacy system for a different platform. Somehow or other, that project went over the waterfall in a barrel too.

    CMM is good but, at least up to level 3, it is about repeatable process, not necessarily good process. I was, in fact, at a company in the final throes of their CMM Level 3 certification, and you would not believe how much stupid but repeatable stuff was in their process.

    You can also game the certification auditors; in the company I was talking about people only had to repeat their processes until they got through the audits, and within a week reverted from stupid but repeatable to just plain crazy.

    CMI also has a Personal Software Process, which certainly helped me in my early days. Highly recommended, but PSP is a lot to take in for a beginner.


    I've seen a few projects where the standard waterfall process worked well, but the vast majority I've worked on seem best suited for agile methodologies.  Since most of the time I'm a Solutions Intgrator rather than a Programmer, I deal with more projects where requirements are stable because I'm not limited to coding a solution - I may just implement a canned package. For example, I was tasked with migrating the existing outsourced email solution to an inhouse Exchange server.  Given the fact that email technology is mature and requirements are not likely to change, it makes sense to follow the waterfall methodology.  I also do not work within an organization whose primary business model is software development; rather I gravitate towards manufacturers due to my engineering degree.  If I did work in a software development company, I might be exposed to development project on more mature applications where waterfall may make more sense.

    As far as CMMI goes, it is definitely unfortunate that people abuse the intent of the framework.  The goal of CMMI is about repeatable and good processes.  It is just like Statistical Process Control, you need to have consistent inputs to a process before you can trust any analysis of the outputs.  If your inputs are unstable ie non-repeatable, than any analysis is spurious at best.  That is why the focus is on repeatability up to level 3.  Only after level 3, can you begin to improve the process because you've effectively eliminated any noise.

    I agree that CMMI is a lot for a beginner to take it, but I mentioned it for two reasons.  First, CMMI also includes business processes which went hand-in-hand with my comment about internal understanding of business processes being a source of instability.  Second, many of the concepts of CMMI are also featured in various SOX Frameworks which some of us need to work under.  Becoming familiar with it might help you further your career if you transition to organizations who need to comply with those regulations. 




  • @lpope187 said:

    @RyuO said:

    Sensible comments, but how many of us have seen stable enough requirements for Waterfall to work? I've seen maybe one, but it was a fluke where the mission was to produce a workalike of a legacy system for a different platform. Somehow or other, that project went over the waterfall in a barrel too.

    CMM is good but, at least up to level 3, it is about repeatable process, not necessarily good process. I was, in fact, at a company in the final throes of their CMM Level 3 certification, and you would not believe how much stupid but repeatable stuff was in their process.

    You can also game the certification auditors; in the company I was talking about people only had to repeat their processes until they got through the audits, and within a week reverted from stupid but repeatable to just plain crazy.

    CMI also has a Personal Software Process, which certainly helped me in my early days. Highly recommended, but PSP is a lot to take in for a beginner.

    I've seen a few projects where the standard waterfall process worked well, but the vast majority I've worked on seem best suited for agile methodologies.  Since most of the time I'm a Solutions Intgrator rather than a Programmer, I deal with more projects where requirements are stable because I'm not limited to coding a solution - I may just implement a canned package. For example, I was tasked with migrating the existing outsourced email solution to an inhouse Exchange server.  Given the fact that email technology is mature and requirements are not likely to change, it makes sense to follow the waterfall methodology.  I also do not work within an organization whose primary business model is software development; rather I gravitate towards manufacturers due to my engineering degree.  If I did work in a software development company, I might be exposed to development project on more mature applications where waterfall may make more sense.

    As far as CMMI goes, it is definitely unfortunate that people abuse the intent of the framework.  The goal of CMMI is about repeatable and good processes.  It is just like Statistical Process Control, you need to have consistent inputs to a process before you can trust any analysis of the outputs.  If your inputs are unstable ie non-repeatable, than any analysis is spurious at best.  That is why the focus is on repeatability up to level 3.  Only after level 3, can you begin to improve the process because you've effectively eliminated any noise.

    I agree that CMMI is a lot for a beginner to take it, but I mentioned it for two reasons.  First, CMMI also includes business processes which went hand-in-hand with my comment about internal understanding of business processes being a source of instability.  Second, many of the concepts of CMMI are also featured in various SOX Frameworks which some of us need to work under.  Becoming familiar with it might help you further your career if you transition to organizations who need to comply with those regulations. 

    Good point about Waterfall being more suitable for solutions
    integrators than custom software. Oracle has an inhouse process called
    AIM they use for the ERP and CRM implementations. It is structured to the
    point of rigidity, but they seem to hit their marks most of the time.
    You'd think Oracle would apply the principles that work for their COTS
    products to their custom software, but no, those efforts are just as
    chaotic as anybody else's.



  • @Ringo said:

    I am a 31 year old accountant (soon to be 32!), and I was curious as to anyone's thoughts of a career change into programming at such an ancient age.  I have been told that an "accounting aptitude" is virtually synonymous with a "programming aptitude" and I would have to agree with this insofar as my limited, self-taught, programming experience is concerned.  How feasible is this, really?

    What would you like to build (create) as a programmer?



  • @Oscar L said:

    It sounds like you have the potential to be good with software.  I hope to someday be good with software, too :P.  You'd be surprised how many actual working programmers don't "get" that.  This is typically where you can expect to see several comments bashing Java programmers, but like violence in old movies, I'll leave the gory slights to your imagination.

     

    Sorry about the hiatus ...

    Thanks, Oscar.



  • Alex Papadimoulis:

    Richard Nixon:
    Who are you to tell me that my particular form of entertainment and enjoyment is less valid than yours?

    I, too, enjoy programming; this is one reason why I chose this field. I did not mean to imply that it isn't fun, but that in the context of all other things done for fun (social activities, watching movies, hiking, etc), it should not be considered the "most fun." If, however, the "fun factor" of programming does rate higher than everything else ... that's probably not healthy.


    Uh-oh. I guess I also enjoy reading about programming and working on physics, too. Oooh, and math...

    Anyway, to overgeneralize what Oscar L already said, "It's not the tool, but the technique." Tools change... and quickly, in this field. Often before the old tool's potential is realized. The underlying techniques and processes change with a great deal less frequency, and I would consider them more important. The basics of set theory, and algorithms will take a you a great distance toward never seeing your code on this site. Of course, you still need tools to get any work done, but which tool to use is dictated by the problem, and less your lack of knowledge.

    Of course, there are extra benefits to specializing in a tool, too.

    I'm afraid I fall closer to CPound than Alex as to enjoyment, but I do know good programmers that don't enjoy it. No offense intended, Alex, but I simply haven't met any EXCELLENT ones that do it for purely financial gains. It's usually satisfaction of some other sort, followed by financial compensation. Of course, I'm still young enough to have my ideals...

     

     

     

    Many of the former "giants," upon whom's shoulders modern science rests, worked 16+ hours a day solving their respective problems.  Whether it was enjoyment, a quest to solve the seemingly unsolvable or both, it was personalities of this order that opened the doors for the great advancements of our modern era.  I'm thankful for personalities such as Richards because without them, life would remain status-quo. 



  • @DrPizza said:

    @Ringo said:

    @DrPizza said:

    Don't bother.  Better money to be made in accounting, better long-term prospects too.

    You are probably right ... but, the whole issue with me is job satisfaction.  I need to strike a proper balance ...

    Then get a hobby.

     

    I have many hobbies but to express my sentiments in as sophisticated a manner as possible, I'd have to say: Work still sucks!



  • @mnature said:

    Ringo, having been involved in computers/technology/engineering for most of my life, and now being a few years away from retirement, I would like to share just a few thoughts.

    It is quite possible to enter a programming career with no formal training.  However, most managers are unaware of that, and one of the first questions you will get (if you even get to an interview) is going to be about your training.  Just imagine how you are going to word your resume about being self-taught (without actually lying about it).  Now imagine defending that at a formal interview.  There are also a lot of unemployed programmers out there right now.  With the end of the cold war, and many companies deciding to go with a "world economy," there will continue to be unemployed programmers for many years.  There is something to be said about an unhappy job that has a good chance of being there for many years to come.  I know a number of programmers who would be happy to be complaining about their boring job (if they only had one).  Also, most programming jobs are actually temporary jobs.  You would be there to do a project, and then get laid off when the project is done.  You would work for a lot of different companies, and that doesn't look very good on a resume, either.

    I think that the advice of pursuing an advanced degree which would combine your accounting skills with some computer skills would be a good way of getting your feet wet, without completely changing your career options.  As a word of caution, though:  As you get older, an advanced degree is not always seen as advantageous by the hiring managers, because it means they will have to pay you more.  Most managers would rather hire staff that are cheap, rather than competent.  You might consider educational programs where you get a certificate of accomplishment, rather than an actual degree.  With the increase in age before you can draw Social Security, you will want to remain employable as long as possible.  I know it seems like an infinite amount of time before you get to that point, but you will be laying the foundation today for what will happen in the next several decades.

    However, after saying that, if you really desire an advanced degree you should probably go ahead and get it.  Some of the hybrid degrees (accounting/programming) have their own niches in industry.  As long as you have your primary accounting degree to fall back on for bread-and-butter jobs, you have a lot of freedom for pursuing something else, either as a hobby or a second career.

     

     

    Thanks for your perspective, mnature.  Yes, I'd have to agree that combining the skill sets would be the best approach.  I've been reading a little about IT audit which holds not only job satisfaction promise, but also the potential of tremendous financial gain.  But, unfortunately, my areas of expertise in accounting do not include auditing: it would be as new as programming/IT. 



  • Thanks, Hank.



  • @RyuO said:

    Lots of good advice from Alex and others. I'll add:

    • The accounting industry is hungry for accountants with programming skills. There are plenty of accountants who spend a large part of their day doing database programming. Once you know that you can lateral into a full-time programming job easily.
    • Enterprise software gets a bad rap around here, and they do have their moments, but if you become an expert in one their accounting modules you can write your own ticket. One easy transition is to become an expert in a niche ERP programming language, like Oracle Forms or ABAP/4.
    • If you can stand working for one of the big consulting firms, they'll be happy to help you broaden your skills. The conditions are pretty awful, but you learn a lot in the 2-3 years you're there.


    Would you mind elaborating a bit more on these three points?



  • @olddog said:

    @Ringo said:

    I am a 31 year old accountant (soon to be 32!), and I was curious as to anyone's thoughts of a career change into programming at such an ancient age.  I have been told that an "accounting aptitude" is virtually synonymous with a "programming aptitude" and I would have to agree with this insofar as my limited, self-taught, programming experience is concerned.  How feasible is this, really?

    What would you like to build (create) as a programmer?

    A great question for which I have a poor answer: I don't know. 

    Honestly, if I really did pursue this beyond the realm of fantasy and personal enjoyment, I suppose I'd let the market (demand) dictate the focus of my learning, energy and efforts. 

     



  • I have most appreciated your thinking, RyuO: thanks!



  • In the business world, MS is the preferred platform, that means you want to go the .Net avenue.  I recommend you buy the following two books, a steal at $11 and they come with all the software you need (a small free version of Visual Studio and a small free version of SQL server).

    Build a program new /w Visual C#.Net 2005
    http://www.amazon.com/gp/product/0735622299/

    Build a web page now /w Visual Studio.Net 2005
    http://www.amazon.com/gp/product/0735622124/


    If you feel you like where this is going, check Amazon for more in depth books.  As for as education, I recommend you merely buy books and take MS's MCAD ( http://www.microsoft.com/learning/mcp/mcad/ ) and MCSD ( http://www.microsoft.com/learning/mcp/mcsd/ ) certification, which cost pocket change compared to classroom learning.



  • @Ringo said:

    @RyuO said:
    Lots of good advice from Alex and others. I'll add:

    • The accounting industry is hungry for accountants with programming skills. There are plenty of accountants who spend a large part of their day doing database programming. Once you know that you can lateral into a full-time programming job easily.
    • Enterprise software gets a bad rap around here, and they do have their moments, but if you become an expert in one their accounting modules you can write your own ticket. One easy transition is to become an expert in a niche ERP programming language, like Oracle Forms or ABAP/4.
    • If you can stand working for one of the big consulting firms, they'll be happy to help you broaden your skills. The conditions are pretty awful, but you learn a lot in the 2-3 years you're there.

    Would you mind elaborating a bit more on these three points?


    <font size="4">Accountants with programming skills</font>
    At a mundane level, there are never enough IT people to do stuff like run a database query and pipe the result set into Excel. Or, write VB macros to convert all the various date formats from servers and clients. Or, write a prototype application in Excel or Access so the IT people can simply see what the requirements are, instead of blundering around in verbiage. Needless to say, if you can do those things, you're more than halfway to a programmer job.

    On a strategic level:
    There are not many people who can bridge the gap between software and accounting - both populations are infamous for communicating badly outside their disciplines. I knew one guy who was a European equivalent of a CPA who somehow ended up as a junior programmer on a huge American mortgage industry project. IT and Accounting were on bad terms, which meant, basically, no requirements. The CPA guy was able to analyze the financial requirements enough (even though he didn't know the industry), and talk to programmers enough (even though he didn't know software that well) to break the deadlock, and eventually became the only indispensable resource on the project.

    Software people are incapable of understanding a business more than superficially. That's a by-product of a good thing - we're trained to zero in on a model that is simple enough to code from, and then we stop thinking about the model. The dumber programmers are likely to think the model IS the business, in the same way as the dumber accountants think businesses exist to produce financial reports.The smarter accountants, OTOH, have the training and experience to understand the business at a much deeper level.

    <font size="4">Enterprise software</font>
    The current generation of ERP and CRM software is highly configurable, meaning that a power user who knows something about the business can do much of the work that used to be teams of programmers. To do that well, though, you need to know when to configure and when to customize (with new code). Somebody who has both the technical and business ("functional", they call it) knowledge to make those decisions are valuable. So let's say you get a "functional" job based on your accounting credentials with a consulting firm that does Oracle Financials implementations. Over time you can learn everything there is about Oracle Apps, including the technical stuff. You'll have a lucrative niche you can stay in forever, or you can seamlessly become more technical.

    <font size="4">Sleaz^H^H^H^H^H Big consulting firms</font>
    The way the big consulting firms (especially the ones who were accounting firms originally, but all of them, to an extent) work is by taking smart people who don't know anything and getting them great resumes. They make the sale at the highest level (such as by taking the CxOs on a yacht to the Greek isles, I'm not kidding), but they make their money on the flunkies. Getting into these companies is hard - they generally hire kids from famous colleges or people with prestigious work experience. You also have to look good in a suit and speak well. One of them even requires you to pass a personality test. Seriously! You take the Myers-Briggs and have to come out ESTJ, I think it is. Maybe I'm just bitter because I only have one of the four letters...

    Once you're in you'd be billed at $250/hour, say, as a "Senior Accountant" and you'd get maybe $80 of that. If you're on the bench for a while, they might bill you as a "Senior Consultant" at the same rate, but you'd now be a Java programmer, whether or not you know anything about Java. If you are not defenestrated by an engraged customer (and they'd pull you as soon as you had a good bullet on your resume), on your next project you might be a "Senior Java Architect". If you survive enough of those "skill enhancements" you'd be partner track.

    Would you learn anything on those projects? Not unless you worked your ass off the side, and either way, you'd be miserable if you were at all professional. The good side is that you'd get great credentials, making a real job easier to transition to. Not only that, but as long as the company has not been disbanded or indicted much , it'll have some cachet with other big companies.



  • @travisowens said:

    In the business world, MS is the preferred platform...


    Can that be true for software development? In my corner of the world (American projects run by consultants) the ratio of Java to Microsoft projects is at least 5 to 1. That's just in Microsoft's bailiwick, little computers - on the server side it's even more lopsided. Completely dominated by some combination of Linux, Unix, Oracle, and mainframes.

    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology, and I have a grudging respect for C#. I use Windows on PCs more than I use Linux or BSD (my first love).



  • @RyuO said:

    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology
    Skrrrrrreach! (sound of breaks squealing to a halt) What do you mean you hate Java?!?

    Once again, not trying to start any holy wars here, but I think you owe the readers an explanation.

    You sound like an experienced architect/developer, that's why this comment does not make sense to me. During my career I have noted that the more experienced the developer, the greater the passion for Java.

    I think it has to do with the fact that Java as a platform and language are "harder to grasp" technologies. Therefore, the advanced developer thinks he sounds cooler if he says he likes Java.

    Based on its technical merits, what are your issues with Java?

    (By the way, I personally believe that Java is a late-90's language which is on its way out...there's just too many other good options these days to depend on such an antiquated platform/language...)



  • @CPound said:


    By the way, I personally believe that Java is a late-90's language which is on its way out...there's just too many other good options these days to depend on such an antiquated platform/language...


    Please elaborate... which are those other good options you refer too? The only comparable plattform that comes to my mind is .net, but it is in practice currently too much tied to Wintel, despite all the efforts that go into mono and dotgnu/portable.net.



  • @CPound said:

    @RyuO said:
    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology
    Skrrrrrreach! (sound of breaks squealing to a halt) What do you mean you hate Java?!?

    Once again, not trying to start any holy wars here, but I think you owe the readers an explanation.

    You sound like an experienced architect/developer, that's why this comment does not make sense to me. During my career I have noted that the more experienced the developer, the greater the passion for Java.

    I think it has to do with the fact that Java as a platform and language are "harder to grasp" technologies. Therefore, the advanced developer thinks he sounds cooler if he says he likes Java.

    Based on its technical merits, what are your issues with Java?

    (By the way, I personally believe that Java is a late-90's language which is on its way out...there's just too many other good options these days to depend on such an antiquated platform/language...)

    You asked about the technical merits, but half my issues are non-technical. Here are what I think are the technical "bad things", though:
    1. As Java was designed to be the "one true religion" and as such has too many features. For example, there is one syntax for base classes and syntax for derived classes.
    2. The identification of compilation units with physical files was obsolete when Java came out, and now it is just plain crazy. Last year I was on a project with <font size="5">28,000</font> source code files, and neither Ant nor the programmers could keep up. Some 50-odd programmers spent most of the day getting the nightly build to work.
    3. Even though Java is supposed to be an OO language, it attempts to tackle non-OO problems with kludges such as Hibernate. You can argue the Hibernate is just an add-on, but the Java community sees it as a patch.
    4. Because it is billed as a "cure for what ails you" Java is used where its lack of raw speed is an issue. If you need fast, you can't beat C on Unix or Ada in a virtual machine, but no, everything has to be Java nowadays.
    Looking back on what I just wrote, I see that it is very hard to separate Java's technical failings from its being oversold in the market. I should note that I have no problems with Java as a niche player - small apps in embedded apps and network programming, and in fact, I have selected it as the technology for implementing agents in a coordinated network.



  • @CPound said:

    @RyuO said:
    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology
    Skrrrrrreach! (sound of breaks squealing to a halt) What do you mean you hate Java?!?

    Once again, not trying to start any holy wars here, but I think you owe the readers an explanation.

    You sound like an experienced architect/developer, that's why this comment does not make sense to me. During my career I have noted that the more experienced the developer, the greater the passion for Java.

    I think it has to do with the fact that Java as a platform and language are "harder to grasp" technologies. Therefore, the advanced developer thinks he sounds cooler if he says he likes Java.

    Based on its technical merits, what are your issues with Java?

    (By the way, I personally believe that Java is a late-90's language which is on its way out...there's just too many other good options these days to depend on such an antiquated platform/language...)

    My non-technical issues with Java are greater than the technical ones:
    • Java has been accepted as the one true religion when it is really more suited for a niche market. Most programmers, especially OO programmers believe this, so it is very hard to get people to think in any other terms. I used to argue with a first-class, very smart, Java guy about OO theory, and we could only get so far because his definition of OO was "whatever Java does".
    • Java elitist culture has led people to add patch upon patch to Java to fix its weaknesses, when anybody in their right mind would refactor it or start fresh. Try loading up Eclipse with all the various plugins you might need on one project and see what happens - not pretty. A lot of these things, like Hibernate, Spring, and Appviews, basically don't work, or work less well than the problems they are trying to address.
    • Because Java is omnipresent, it squeezes out deserving technologies and programmers, much like kudzu. For example, I'm starting to think Ruby and Rails do a lot of Java's core functionality better than Java does, but they are still novelties. And don't get me started on Ada...
    • Java has ushered in an era of closemindedness, which is bad for the industry as a whole. Make no mistake, software engineering is still in its infancy. It is way too early for the one true religion to emerge.
    • Java is not exactly proprietary, but it is not exactly open either. Behind Java is a major company that would go out of business in a year without it, and the result is bad for quality.



  • @CPound said:

    @RyuO said:
    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology

    ...You sound like an experienced architect/developer, that's why this comment does not make sense to me. During my career I have noted that the more experienced the developer, the greater the passion for Java...

    Forgot to address this point in the earlier post. Sorry about the quality of my editing in the last couple posts - I need an "edit" button.

    What I think has happened is that the people who fill most of the architect and tech lead slots came along after 1996, when Java was revealed as the one true religion. That's all many of their generation have ever known, and all they may know to compare them to are scripting languages like perl and VB and whatnot. If they were slightly older they may remember the short period when C++ was dominant and at least suspect Java is not the only answer, but they are few in number because the burnout rate is so high.

    If you're ancient like I am you'll remember back to when there were a hundred technologies that had valid raison d'etres:
    • OO languages that were as good then as Java is now, like Smalltalk and Eiffel
    • Close-to-the-machine languages like C
    • Mainframe languages like COBOL and PL/1
    • Specialist languages like FORTRAN and SAS
    • All sorts of scripting languages such as the ones still on Unix
    • General-purpose languages like Ada and Modula-2
    So I'm firmly imprinted with the principle that you have to pick the right technology for the job. If I can resist the tendency to think "they don't make'm like Honus Wagner any more" I'll do it well, because, for one thing, the bar is set pretty low. You might notice that job listings ask for "Java architect" instead of "specialist in N-tiered architectures with a thin client front end". A real architect will know why he picked an architecture and what the alternatives are, while the "Java architect" will probably pick a recipe from the Java cookbook.



  • @ammoQ said:

    Please elaborate... which are those other good options you refer too? The only comparable plattform that comes to my mind is .net, but it is in practice currently too much tied to Wintel, despite all the efforts that go into mono and dotgnu/portable.net.
    I apologize. I meant option (singular). The .NET platform is the only legitimate successor to the Java age.@RyuO said:
    • Java has ushered in an era of closemindedness, which is bad for the
      industry as a whole. Make no mistake, software engineering is still in
      its infancy. It is way too early for the one true religion to emerge.
    • Java
      is not exactly proprietary, but it is not exactly open either. Behind
      Java is a major company that would go out of business in a year without
      it, and the result is bad for quality.
    I think you hit the nail right on the head. In order for us to progress as a software engineering community, Java must die.



  • @CPound said:

    @ammoQ said:
    Please elaborate... which are those other good options you refer too? The only comparable plattform that comes to my mind is .net, but it is in practice currently too much tied to Wintel, despite all the efforts that go into mono and dotgnu/portable.net.
    I apologize. I meant option (singular). The .NET platform is the only legitimate successor to the Java age. (...)
    In order for us to progress as a software engineering community, Java must die.

    It took .net to bring some movement into Java (Java 5 was heavily inspired by C# features). In the same way, .net needs the competition from Java. Without competition, there is no innovation.



  • @Ringo said:

    @no, it was not ammoQ, learn to quote (your friendly moderator) said:

    computer science degree is meaningless, don't bother

    Please elaborate ....



    This is getting a little OT, but the discussion was getting off topic anyways.

    I wanted to share my perspective as one of those in the industry without a computer science degree. I began programming very young. Right out of high school I landed a job doing web development part time while attending a private university working toward a CS major. After a few months there I was "promoted" to working with a team (of 2) to do a Windows database front-end application. My pay sucked (seriously, $8/hour, and I practically architected the thing), but while I was coding this very large and in my opinion very cool application at work, I was doing rather mundane things at school. I wound up dropping out of school after a year and a half and started working full time. Perhaps not the smartest move I've ever made, but its done now. Like I said, the pay sucked, so after another half year (making 2 years at this company), I quit and was hired by another company that was significantly larger with a very nice pay raise (a few times my old pay). I've now been there for over a year.

    I'm about to turn 21, and I have no college degree in sight. However, I'm about to turn 21 and I have over 3 years "professional" work experience, plus about 7 years of homegrown experience before that. I've been a homeowner for about a year now, when most of my peers are probably quite a few years away from that. So... point being, from the "immediate" perspective, having no degree right now is working out quite well for me.

    Now looking to the future, its hard to say. I've often wandered how hard it will be to move on from here. So far not having a degree hasnt been a problem when interviewing, but of course I havent interviewed for any senior positions. I'm hoping that two things will happen: 1) My previous work experience and ability to demonstrate (without trying to be too boastful) my fairly good knowledge of software development in general will make up for the lack of degree and 2) More and more decision makers will realize that, at least from my experience, a degree is not all its cracked up to be.

    Let me explain, which gets me to the actual point of my post and answer to the original question. When I did attend the university, I had a chance to observe my fellow student peers, and to be honest, I was not at all impressed. Nor was I impressed with the quality of assignments that was given to us. I personally did not find the assignments challenging, and learned very little while there (thus the motivation for dropping and working full time). Meanwhile every other student (granted, it was a private university, so only about 10-15 people per class) quite frequently scored 50% or lower on tests, and the professors would apply a curve so that the entire class would not fail. To get to the point, I felt like when it was all said and done, the actual learning and the certification of said learning was pretty much worthless, and a far cry from having actual real world experience, whether homegrown or professional. I'm sure there are university programs out there that are worth their weight in gold, but mine wasnt one of them, and from the general *gist* that one gets from forums like these and personal anecdotes, many "trained professionals" can make some fairly critical mistakes that can be solely attributed to lack of experience.

    Degrees might not be worthless and may still play a role in attractiveness for a position and pay grade, but I know that if I were the decision maker, I would be much much more interested in the actual abilities and accomplishments of the candidate, and I'm hoping that my future employers will have similar feelings.

    Or I could just always start my own business.

    P.S. Sorry for the long run-on sentences. A fault of mine.


  • @RyuO said:

    @CPound said:
    @RyuO said:
    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology

    ...You sound like an experienced architect/developer, that's why this comment does not make sense to me. During my career I have noted that the more experienced the developer, the greater the passion for Java...

    ...What I think has happened is that the people who fill most of the architect and tech lead slots came along after 1996, when Java was revealed as the one true religion...


    Looking back on what I wrote, I don't think I communicated the spirit of the Java "establishment" very well. The Manhattan view of the world is a good analogy:
    http://www.magazine.org/Editorial/40-40-covers/4.jpg
     In a like manner, Javalytes see any technology not built around Java as significant and probably questionable. For example, that's why they are the ones most likely to advocate the bane of my existence, "database independence" (they mean "DBMS independence", but WTF, it's insignificant). That means they duplicate in Java the functionality of what is not common to all DBMSes (physical storage, maybe transactions and locking). Not smart from a performance or cost point of view.




  • @RyuO said:

    @CPound said:
    @RyuO said:
    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology

    ...You sound like an experienced architect/developer, that's why this comment does not make sense to me. During my career I have noted that the more experienced the developer, the greater the passion for Java...

    Forgot to address this point in the earlier post. Sorry about the quality of my editing in the last couple posts - I need an "edit" button.

    What I think has happened is that the people who fill most of the architect and tech lead slots came along after 1996, when Java was revealed as the one true religion. That's all many of their generation have ever known, and all they may know to compare them to are scripting languages like perl and VB and whatnot. If they were slightly older they may remember the short period when C++ was dominant and at least suspect Java is not the only answer, but they are few in number because the burnout rate is so high.

    If you're ancient like I am you'll remember back to when there were a hundred technologies that had valid raison d'etres:
    • OO languages that were as good then as Java is now, like Smalltalk and Eiffel

    As far as OO is concerned, Smalltalk is not "as good then as java is now", Smalltalk was (and still is) frighteningly better than Java will ever be.

    If anything because Java is a marketting-driven language that went for market share, while smalltalk went for purity (and got binned when marketroïds heard of java)

    And even features that are now touted as Impressive Features of Java or C# (advanced IDEs with strongly integrated and powerful refactoring, unit testing, ...) were created for and on Smalltalk. And arguably lost quite a bit of power in the transition.



  • @masklinn said:

    @RyuO said:
    @CPound said:
    @RyuO said:
    To disclaim any personal bias, I'll note that I hate Java more than I ever hated any technology

    ...You sound like an experienced architect/developer, that's why this comment does not make sense to me. During my career I have noted that the more experienced the developer, the greater the passion for Java...

    ...If you're ancient like I am you'll remember back to when there were a hundred technologies that had valid raison d'etres:
    • OO languages that were as good then as Java is now, like Smalltalk and Eiffel

    As far as OO is concerned, Smalltalk is not "as good then as java is now", Smalltalk was (and still is) frighteningly better than Java will ever be.

    If anything because Java is a marketting-driven language that went for market share, while smalltalk went for purity (and got binned when marketroïds heard of java)

    And even features that are now touted as Impressive Features of Java or C# (advanced IDEs with strongly integrated and powerful refactoring, unit testing, ...) were created for and on Smalltalk. And arguably lost quite a bit of power in the transition.



    Ooh, I like that guy! Masklinn is right, so please address any pro-Java posts to him.

Log in to reply