• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Future is products market

 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Right now I am working on a BPM tool(http://www.pegasystems.com). It has been built on J2EE archietecture. But we need not write a single line of java code to do projects with it.

My doubt is does it gives good future??? or working on J2EE technology gives good future?

I heard in future all r this type of tools or products only. What is your opinion?

Regards,
Murali
 
Ranch Hand
Posts: 1871
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I was in college one of our professor told that development work will be almost finished by 2020, the most of the developers will be involved in integrating the components and hardcore development will be done by very few professionals who will develop the components.

Well we can see how effective is this PegaRules Process Commander in comparison to Java IDE. In order to change the application we just need to make changes to Visio flow diagrams, which automatically drive changes to the rules in Process Commander whereas in Java IDE we have to change the source code.

I think in future most of the developer wont be writing any code they will be assembling the components according to the requirement of a particular business process. I would slightly change what you say that Future is of Component market.
[ May 19, 2004: Message edited by: Sameer Jamal ]
 
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Some thoughts...

I agree that the trend is towards components, but I think there will always be a need for new software.

Technological developments continue, and no-one is saying all hardware will be built by 2020. If this is the case, surely not all software can be. I'd say that in well-known markets (desktop/enterprise apps: CRM systems, document management systems blah blah), product development will slow down. Equally, other areas will pick up:

  • computing on mobile devices
  • Internet apps, particularly as bandwidth increases (video/audio stuff, real time collaboration blah blah
  • Software for hardware that doesn't yet exist, and applications that take advantage of that hardware/software. Eg, a "virtual reality glove" you can wear to manipulate 3D objects. Great for games and modelling.
  • Software in cars, watches, etc etc. Virtually all electronic devices are getting "smarter" (are gaining in computing power), and someone's gotta write that machine code that runs the dishwasher...


  • I'm sure there are others, but that's all I can think of at the moment.

    Also, I think that companies won't cease developing just because today's product is "good enough". I can't see Microsoft halting at Longhorn, or even the version after that (I think it's code-named "RedHat" ) Equally, in all areas we'll find we need the latest, greatest thing.

    I agree that a drive towards a component market is possible (and likely, even), but only in the most well-known and understood areas of software development, at least in the near future.

    Anyway, my $0.02.


    --Tim
     
    Ranch Hand
    Posts: 5093
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Of course, someone will have to write the software that writes the software that writes the software that creates the components that are used by software to write the software that writes the software...

    I've used generators, and they all produce horrible code that performs abysmally.

    Of course it is every architect's wet dream to be able to just create some highlevel UML diagrams, press a button, and the completely functional application will roll out of his drawing package.
    No more need for those pesky programmers who think they know better with 10 years experience how to create software than you who have come fresh out of your CS master's study...

    It was also concluded in the 18th century that science was complete. Nothing new remained to be discovered...
     
    Ranch Hand
    Posts: 187
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I think there is a lot of scope on improving our coding styles and we can certainly think of finding better ways of doing even simpler coding tasks.( Leave aside J2EE.)
    But I seriously think as with all tools and products there will always be a need for real genius.
    Is not always there a guy in your company to whom you ask for help when you have a most difficult problem with your code or when your code is all correct and somehow it does not work correctly in the application server. What about these guys who can solve such problems just by asking you a few questions as long as they have worked in that area before?
    We will always need people who can solve problems that stump others.
    We will always need someone who can invent new effecient design patterns.
    As far as UML is concerened it can only be a part of the solution.
    Look at MDA now we have so many flavours of XMI. All you need is to be a big company and you can stretch the MDA into a new flavour.

    And yet can we genertate 100% self validating XMI documents? Can we feed in the rules in a XSDand get a totally validating system for a corresponding XMI file? Can we accomodate additional rules easily using XSL and yet get locale independence? Can the XSL extra rules be optimized for production in the generated code using some XSL to Java compilers?

    There is a lot of work to be done and UML has to change a lot.
    The tools and IDEs must really grow up a lot.
     
    Saloon Keeper
    Posts: 27762
    196
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Somewhere about the year 1900, a U.S. patent examiner whose name escapes me quit because "everything had already been invented". This was, of course, right before the airplance, radio, television, computers, lasers, wetc. etc. etc.

    It has been the goal since about the time Grace Hopper pressed the moth in her book that skilled labor (programmers) be replaced with unskilled labor (monkeys) so that the cost of acquiring softwafre customized to the needs of the business would be minimised, that the time to produce it become rigorously predicatable, and so an unruly bunch up uppity overpaid people with delusions of decision-makign (that is "management") skills capable could be tossed out on their collective fundaments.

    It hasn't worked and so far the closest they've gotten to get it to working is to find cheaper people to do it, but still have essentially the same situation.

    Here's why:

    You'd think for example that since accounting is accounting and once you've seen one General Ledger System you've seen them all, so financial software would be a simple block-building exercise.

    Then, however, the government passes the Sarbanes-Oxley act. Or changes the rules on depreciation. Or alters how dividends are accounted for. Now someone has to go in and change the software.

    OK, so obviously the financial software houses have to do something. But that's leveraged. One set of programmers working on new modules that get distributed to all the customers. So there's really no need for programmers in every business across the nation, is there?

    Well, actually, yes. Here's another example. It's also a federal requirement for financial institutions like the one I currently work for to check customers and employees against a federal registry of known or suspected terrorist, drug dealers, and the like. We have a number of canned systems that the data comes from, but someone has to collect that data, normalize it, and feed it to the checking program. Our collection of canned systems is unique to us. We picked them and another company would not necessarily pick the same set. So the task of getting all these identities lined up requires someone who knows specifically our company as well as hour our company uses the data constructs in the canned systems to manage the process. That someone for the last 3 months has been me.

    There's alway something new, or something old that needs renewing. And that's why my previous employer started out with 6 programmers but currently employs hundreds.
     
    Author
    Posts: 6055
    8
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Around the turn of the century, Schroedinger was told not to go into physics, because the field was pretty much all solved. He went into physics anyway and was one of the founders of quantum physics.

    Heck, why do we even need mechanical engineers? The entire field is based on 4 simple tools that were invented centuries ago. Isn't it just assembling different components together--no real creativity?

    One day it would be nice to sit on the bridge of the Enterprise and tell the computer to make a program for you. As Tim pointed out, we still need people to write and modify the code. (Remember that much coding is maintenance coding.) And there will always be new products that need new code.

    I do think the need for people to customize and tweak enterprise systems will increase, but not to the significant detriment of developers.

    --Mark
     
    reply
      Bookmark Topic Watch Topic
    • New Topic