Discussions

News: Opinion: The End of the Beginning?

  1. Opinion: The End of the Beginning? (52 messages)

    It is the end of a year, so Ron Hitchens reflects, and then looks ahead at what "programming" will mean in the future. He believes that software development is entering a mid-life, transformative stage.

    He talks about moving from the world of text, and moving to other representations. Yet another false prophecy of the death of source code as we know it?

    Read: The End of the Beginning?

    Threaded Messages (52)

  2. Opinion: nonsense[ Go to top ]

    "The era of humans translating their thoughts into sequential execution steps is ending."

    Such grandiose language. In the past eras were defined in retrospect by historians. Now they are detected and pinpointed even before they have finished. Perhaps Ron can demonstrate making a peanut butter sandwich without translating his thoughts into sequential execution steps. Whatever programming means in the future, we can be assured that it will include the translation of thoughts into sequential execution steps.

    Unfortunately an era is ending. The era of humans employing reason, logic, and common sense in favor of controversial quips is ending.

    Taylor
  3. not all software created equal[ Go to top ]

    We always talk about software as a whole, but the reality is that there are different types of software that deserve different types of treatment. For example, business applications require different skill sets and use different programming constructs/tools than operating systems, infrastructure software, or games. Raising the abstraction level in a general IDE or 3GL language can only go so far until you start focusing on the specifics of the target software type and the target programming audience.

    For example, in the late 80s, 4GLs had great success focusing on business applications by identifying the most common programming constructs (i.e. data/database structures and user interface forms) and offering tools (higher level abstractions) to streamline the development of these constructs. Accordingly, most of that era's business applications (and even today's largest business application suites--like SAP and Oracle Applications) are built with 4GLs. Unfortunately today, with the popularity of Java and web technologies, developers went back to 3GL constructs to build business applications, and are experiencing a high rate of failure (in terms of projects finishing on time and reasonable budget).

    Don't misunderstand me, 4GLs as we know them had fundamental problems and limitations: no standardization, outdated constructs for representing data structures (tables/columns), outdated constructs for representing user interface forms (took a while to get on the web interface bandwagon), and no clean and coherent constructs for addressing everything else (too much scripting).

    As somebody that has developed a complete 4GL platform in the 80s (using good old Turbo Pascal:-), and architected the first comprehensive platform for executable UML (Intelliun's VE), here is my two cents:

    - we have to think of software in different categories, and business/web applications are way behind the curve in terms of raising the abstraction level.

    - expressing business (or domain) objects in UML Class Diagrams is far better construct than text-based code or text-based forms (like data dictionaries in 4GLs)

    - a lot of the logic that traditionally ends up in text-based code/scripts can be moved into declarative rules (expressions or Excel like formulas) around domain objects and their members.

    - I used to think that UML Activity Diagram is a good way to represent low-level (i.e. object operation level) dynamic behavior or sequential flow of control, but after using them for years in this manner, I now believe that text-based scripts are far more effective. However, the abstraction level of the script can significantly be improved (compare LOC in Smalltalk vs. Java, C++ or C for example).

    - You have to separate application logic into two categories: domain logic and interface logic. Then separate the interface logic into two categories: user interface (where the system responds to external entity's/actor's requests), and resource interface (where the system uses an external entity like a database or another application). The result is the 3-tier architecture applied to application construction.

    - Such separation already exists and is common practice. Unfortunately, text-based code like HTML, JSP, Java, SQL, etc., is still the predominant construct, which leaves a lot of room for improvement.

    - The domain logic must be the focal point and the main area of concern in application development, while the interface logic is kept as transparent and automated as possible.

    - And finally, we have to significantly reduce the time and number of steps between changing the logic and seeing its impact. Consider making a single change to a domain object, and all the manual changes you have to make to the dependent interface logic, the code-generation steps (if you're using more advanced IDE/frameworks), compilation, deployment, and restart of whatever server you're using. That is a lot of time (and in some cases effort), which significantly reduces the number of times you can iterate over and refine your domain logic.
  4. May publish this separately.[ Go to top ]

    Good philosophic thought.
  5. May publish this separately.[ Go to top ]

    Thanks. You're right. Actually, I'm working on an abstract for a series of small articles that discuss business applications and the evolution of technologies that raise the abstraction level of building such software. You have two camps (trends): MDA and the different tools out there, then you got BEA Workshop and Sun Project Rave (following in Microsoft's footsteps...just a decade later:-).

    Add SOA, and 2004 should be really interesting. Happy new year!
  6. May publish this separately.[ Go to top ]

    You have two camps (trends): MDA and the different tools out there, then you got BEA Workshop and Sun Project Rave...

    Anything that generates code from UML is necessarily an example of MDA. So Rave is MDA. BEA goofed by not originally making Workshop do MDA. But BEA realized its mistake and is adding MDA to Workshop. So there's no schism here. All these tools do MDA.
  7. May publish this separately.[ Go to top ]

    Actually, Rave has nothing to do with UML or modeling. In a direct conversation with a Sr. VP at Sun (let's keep him nameless even though that particular conversation was not under NDA), before even announcing Rave, it was clear that he didn't believe in modeling as the way to go. He wanted a VisualBasic like environment for Java. I disagreed with him then as I do now. I believe that the Java community can do a whole lot better than a decade-old Microsoft technology.

    Nevertheless, just in case I missed something, I just checked Sun's Rave home page, and came accross this eWeek article, which also describes Rave as VB for Java. There are a bunch more articles that confirm this.

    Also, even though that Sun claims that their approach is much different than BEA's Workshop, they are the same in concept. Sun is fortunate enough though that they can standarize a new spec. and call their IDE a standard much faster than BEA (or any other company) could through the JCP process. Unfortunately, it's a two sided sword that hurt Sun as much (even more) than they benefited from it...just look at their direct Java revenues compared to BEA, IBM, Oracle, etc.

    Off to a new year party...Enjoy your evening and keep it safe.
  8. Future SE[ Go to top ]

    I agree with many of your points, especially:
    - UML diagram for domain structure instead of text-based code.
    - Text-based code for sequential flow or workflow instead of activity diagram.

    Additionally:
    - Use a pragmatic and a logical approach to make the structure of your application, so that you can manage the complexity of your application project (components, sub-modules, modules, external components, etc.).
    - Separate the "specification" and the "implementation" part of your business layer. Implement your presentation layer independently from your business implementation. The presentation layer should only access the specification part of your business layer!
    - Do forward engineering only, no round-trip.

    Therefore I would say, combining both:
    - MDA (Model Driven Architecture) for the domain structure (UML diagram) and
    - Agile development (sourcecode centric approach) for the sequential flow of your application (text-based code)

    are the future! With this approach you can satisfy both sides: managers and developers.

    Cheers,
    Lofi
    http://www.openuss.org

    BTW. We are doing this at the moment by combining AndroMDA and EJOSA
    http://www.andromda.org and http://ejosa.sourceforge.net
  9. Future SE[ Go to top ]

    I agree, the separation of the presentation layer from domain logic is absolutely a must. This is what I was referring to as interface logic: user interface is the presentation vs. the resource interface is your logic for integrating with existing resources (e.g. existing apps or database).

    The code for the dynamic behavior, however, must be completely technology and architecture independent, representing the domain logic in the purest form. For example, if your code references a ResultSet, a Connection, an InputStream, JNDI Context, or a ServletResponse, then this is not the code I'm referring to.

    In addition, if you're using Java as is (especially pre JDK 1.5), which is a 3GL, then you're not using to most descriptive and appropriate language for capturing domain logic for business or web applications. Having to deal with iterators, primitive wrapper classes, explicit casting, and anonymous inner classes as a block closure, as a few examples, is a complete (and unnecessary) distraction.

    Going back to the presentation layer, most of today's approaches (even in the more appropriate approach you've mentioned), still developers are doing top down then wiring. In other word, GUI/Web developers start with the visual aspect of the interface, then wire it in with the domain logic (the public/external interface part of it). What I'm referring to is the other way around. Your public/external interface, in the form of public domain objects, is immediately visible to the external user. The GUI/Web developer is only altering their look and feel to make them appropriate for the target Actor and the use case specifics. The difference might seem subtle, but the ramifications are tremendous.

    I encourage you to take a quick look at the online demos at intelliun's web site to see what I mean. If you're intrigued, please feel free to download VE/Designer and experience the technology for yourself. (If you do, check out the stock portfolio and the job board examples...they're pretty good).
  10. Future SE[ Go to top ]

    I encourage you to take a quick look at the online demos at intelliun's web

    >site to see what I mean. If you're intrigued, please feel free to download
    >VE/Designer and experience the technology for yourself. (If you do, check out
    >the stock portfolio and the job board examples...they're pretty good).

    Thanks for the link. Fascinating stuff...

    Actually, it's nothing new. We had such tool backs in the late 80s/early 90s. The only difference was that back then everything was based on some proprietary technology. The world was a much smaller place. Consequently, it was much, much easier to build such CASE tools (I've used lots of those 12 years ago).

    I remember one tool we were using back then -- Top *CASE (sitting on top of Oracle).

    Back then I used to think that such tools are a bunch of balloney. After skimming through the Intelliun tool, I had this massive sense of deja vu.

    As fascinating as the tool may appear to younger people only used to fiddling with Struts, or any other existing framework, it is actually incredible clunky and cumbersome. It gives a false impression that the end user need not know the intricacies of the low level coding of a software application. Nothing could be farther from the truth. If you go through the exercise using this product, you'll realize in no time that you're actually doing your regular low-level coding, only sugar coated and masked by some annoying layer of clunky UI.

    All the things that this tool proposes to do for you are very easily doable by hand. And, because you need to understand in very many details the underlying technical concept when using this tool to build an app, you will also know perfectly well how to build all those things by hand, without the annoying noise that the tool introduces.

    So, in that respect, the tool appears as just another one of those 'six one way, half dozen the other'.

    Maybe I'm wrong on this (I admit, I had only a short stab at it), and I'd really like to hope that I'm dead wrong, but unless someone can reassure me and dissuade me from my evil skeptical ways, I'm sticking to my first impression that this is just another unnecessary layer thrown in to make the coding even more murky than necessary.

    Rebuttals?

    Alex
  11. CASE Tools + Future SE[ Go to top ]

    <quote>
    I encourage you to take a quick look at the online demos at intelliun's web
    site to see what I mean. If you're intrigued, please feel free to download
    VE/Designer and experience the technology for yourself. (If you do, check out
    the stock portfolio and the job board examples...they're pretty good).
    </quote>

    Thanks for the link. Yes, it looks quite amazing, just drag&drop and you'll get your application done. But this is not what I thought ;-)

    <quote>
    All the things that this tool proposes to do for you are very easily doable by hand. And, because you need to understand in very many details the underlying technical concept when using this tool to build an app, you will also know perfectly well how to build all those things by hand, without the annoying noise that the tool introduces.
    So, in that respect, the tool appears as just another one of those 'six one way, half dozen the other'.
    </quote>

    I agree with you. Additionally it's important for any software technology to become standard if you can get the "reference implementation" for free. This is also why Java is quite successful. You can get the J2SE, J2EE and J2ME reference implementations for free. This is also the thing that annoys me about OMG, because you cannot get a reference implementation for UML, MDA or CORBA. You only get a specification ;-) The situation is now getting better because of XMI for UML and those Open Source implementations of XMI tools (JMI, etc.). Also there are a lot of Open Source MDA tools available (AndroMDA, architectureware b+m-Framework, etc.). These all the stuffs that make UML + MDA "different" than CASE tools years ago...

    Cheers,
    Lofi.
  12. CASE Tools + Future SE[ Go to top ]

    You make good points. The question is which comes first innovation or standards. I believe that in an uncharted area (which applies here), innovation must come first. If the value proposition is so compelling, and the barriers to entry are relatively low, then wide scale adoption will take place. Once that happens, then it's time for standardization.

    I can point to several cases where standardization (at least premature standardization) stifled innovation, but I will not do so. This will open a can of worms that I don't think I'll be able to keep up with the rebuttal (and still do my day job).

    As far as open-source, it is also one of those can of worms discussions that I will stay away from. Just keep in mind, if there is no financial incentive, there is no reason for anyone to invest in the software industry (capitalism). By the end of the day, somebody has to pay the developers bills...it's not charity! I will stop here, because anything more, and I'm asking for a rebuttal...so please let it go:-)
  13. CASE Tools + Future SE[ Go to top ]

    <quote>
    As far as open-source, it is also one of those can of worms discussions that I will stay away from. Just keep in mind, if there is no financial incentive, there is no reason for anyone to invest in the software industry (capitalism). By the end of the day, somebody has to pay the developers bills...it's not charity! I will stop here, because anything more, and I'm asking for a rebuttal...so please let it go:-)
    </quote>

    Yes, this is true and I agree with you. Therefore I would separate between "technology/infrastructure" (Java - J2EE, J2SE, J2ME, application server, UML, MDA) and "tools" (IDEA, VE, WebLogic Workshop, Sun's Rave, etc.). It shoukd be possible for "everyone" to use the technology like J2EE or Java with compilers, etc.for free. The same should also be applicable to UML/MDA. It should be possible for *everyone* to use them without buying *any* tools! This is just analog to PIM (technology/infrastructure) and PSM (tools) ;-)

    BUT, if you need more "helpers" more comfort (better code editors, better UML tools, better support and service, etc.) you can buy those tools. So for me tools are the "value added" things.

    In this separation, Java is quite successful. You are just a student, no money for those fancy tools? No problem. You want to build your application with J2EE, but cannot afford to buy IBM Websphere? Use JOnAS. No problem. This happens also with UML and MDA in Java shortly. Use AndroMDA or b+m-Framework for working with your XMI/JMI if you cannot afford to buy other commercial tools. If you need speed and have to build your application fast, buy those helper tools available (VE, BEA Workshop, ArcStyler, etc.). You can buy Compuware for MDA, if you need more fancy stuffs in MDA. Yes, you have choices! And this is great.

    Anyway, I see that in the MDA tool area we also have to separate between:
    - Visual Basic oriented tools (VE, Sun's Rave, BEA Workshop, ...)
    - Generative oriented tools (Compuware OptimalJ, ArcStyler, ...)

    Both have pros and cons ;-)

    Cheers,
    Lofi.
  14. CASE Tools + Future SE[ Go to top ]

    Agreed.

    >
    > Anyway, I see that in the MDA tool area we also have to separate between:
    > - Visual Basic oriented tools (VE, Sun's Rave, BEA Workshop, ...)
    > - Generative oriented tools (Compuware OptimalJ, ArcStyler, ...)
    >

    I really wouldn't put all of these guys under MDA. They're rapid-application-development (RAD) technologies, but not all MDA. Also, I wouldn't put VE with the VB camp, which Rave and Workshop are clearly in. The development in VE is completely model-driven, and UML more specifically. So, it is clearly in the MDA camp. However, even though MDA encourages code-generation, it doesn't require it. I view VE as more in an Executable UML category under MDA, which is fairly unique. OptimalJ and ArcStyler are on the code-generation side of MDA.

    That said, it is far more productive to develop on top of an executable UML VM (like VE) for reasons I mentioned in other posts in this thread. That doesn't preclude you from making the code-generation as part of the final deployment process...getting the best of the two worlds. In addition, you are inssured of two things that the code-generator MDA tools cannot offer:
    - your logic is completely technology neutral
    - if you can deploy/code-generate to one technology language/architecture, you can do it to any (say C# on .NET if you so inclined).

    It's much easier to add code-generation templates (which VE already does for doc generation and embedded Java implementation support) to an executable UML VM, than to add executable UML VM to a code-generation MDA tool. Just some pros and cons.
  15. CASE Tools + Future SE[ Go to top ]

    <quote>
    I really wouldn't put all of these guys under MDA. They're rapid-application-development (RAD) technologies, but not all MDA. Also, I wouldn't put VE with the VB camp, which Rave and Workshop are clearly in. The development in VE is completely model-driven, and UML more specifically. So, it is clearly in the MDA camp. However, even though MDA encourages code-generation, it doesn't require it. I view VE as more in an Executable UML category under MDA, which is fairly unique. OptimalJ and ArcStyler are on the code-generation side of MDA.
    </quote>

    Again I agree with you ;-) I tend to categorize those MDA tools (UML based) in:
    - Two-Ways-Tools (executable UML): Together, VE
    - Generative Tools: OptimalJ, ArcStyler

    Sun's Rave, BEA Workshop cannot be mentioned as MDA tools because they do not use UML as their core.

    Lofi.
  16. CASE Tools + Future SE[ Go to top ]

    You make good points. The question is which comes first innovation or

    >standards. I believe that in an uncharted area (which applies here), innovation
    >must come first. If the value proposition is so compelling, and the barriers to
    >entry are relatively low, then wide scale adoption will take place. Once that
    >happens, then it's time for standardization.

    Sounds like a Microsoft business plan to me. Microsoft is a large enough company to invest in innovations and then pour billions into creating the market for such innovations. They are plainly the "software pushers".

    But smaller companies look comically misplaced when they try to follow Microsoft's lead. They simply don't have the clout to create new markets out of thin air. Yes, they can 'innovate' till the cows come home, and they can produce 'giant solutions in search of a problem', but the much coveted wide scale adoption won't take place.

    When was the last time wide adoption took place in the software world? I'd say a couple of years ago, with Struts. Ever since then, nothing else happened on that front.

    When will the next wide adoption take place? No one knows. But one thing is clear -- such things are not guaranteed to happen every year.

    Personally, I don't think we need much innovation in the software implementation arena. What we need there is to step up the education. We need more educated developers, not more expensive tools.

    Where we do need all the innovation we could possibly muster is in the software requirements and software design arena. But, nothing seems to be happening in that world. We're still stuck with the decades old practices and rules of thumb.

    Alex
  17. CASE Tools + Future SE[ Go to top ]

    Personally, I don't think we need much innovation in the software implementation arena. What we need there is to step up the education. We need more educated developers, not more expensive tools. Where we do need all the innovation we could possibly muster is in the software requirements and software design arena. But, nothing seems to be happening in that world. We're still stuck with the decades old practices and rules of thumb.


    Have you heard of model governance? It means that the tool dictates the design. So better tools would mean better design. So we *do* need better tools.
  18. CASE Tools + Future SE[ Go to top ]

    Personally, I don't think we need much innovation in the software

    >>implementation arena. What we need there is to step up the education. We need
    >>more educated developers, not more expensive tools. Where we do need all the
    >>innovation we could possibly muster is in the software requirements and
    >>software design arena. But, nothing seems to be happening in that world. We're
    >>still stuck with the decades old practices and rules of thumb.


    >Have you heard of model governance? It means that the tool dictates the design.
    >So better tools would mean better design. So we *do* need better tools.

    You've conveniently glossed over my 'software requirements' issue. What good is a good tool that dictates a good design, if the requirements are ludicrously misrepresented, and the end result is a piece of crap? A well designed piece of crap, mind you, but nevertheless -- crap!

    Alex
  19. CASE Tools + Future SE[ Go to top ]

    Have you heard of model governance? It means that the tool dictates the design.

    >So better tools would mean better design. So we *do* need better tools.

    Oh yeah, forgot to mention this -- good design only comes out of good, solid thinking. Tools, even better tools, as far as I'm aware, cannot aid us in thinking. Tools can only help or assist us in expressing our thoughts.

    So, better tools do not imply better design. And that's especially true in the virtual world, where everyting is a pure concept anyway.

    Alex
  20. Future SE[ Go to top ]

    You're right in that raising the level of abstraction, especially via visual models, is nothing new. The history of software engineering is full of failed attempts. However, you have to keep an open mind that one day, one technology will break through this barrier and succeed in delivering on the promise. I happened to believe this technology is VE, but again, I'm a little bias:-)

    True, with today's standardizations (e.g. UML, XML, HTML, etc.) and broad advancements in software technologies (e.g. platform neutral languages, and out-of-the-box architectures like J2EE), it is more achievable to build such a platform. On the other hand, because of all of these technologies and the steep learning curve, such platform is the natural evolution for building web and business type applications. And no, this is not a threat to programmers (like some of the posts suggested). On the contrary, it is an empowering technology that shifts the programmer's focus from mundane activities to building more feature-rich and quality applications (who had to cut corners because of deadlines:-)

    Back to the specific point you made, unlike most of the MDA tools that generate an obscene amount of code for every domain object--code like you said that you have to understand in order to complete, VE doesn't generate any code. The second you add a class to your class diagram, you can select it and press the play button and interact with it in a browser. You can add more details, rules, and related object, then press the play button again and you're interacting with and validating the new logic. No code-generation, compilation, deployment or restart. No need to understand how it works under the hood--except for very few concepts that you have to know anyway if you're doing analysis or abstract design. I ran an example in one of these MDA tools (let's keep it nameless) that started with 2 (it might have been 3) domain objects then I selected the generate menu item, and I got more than 60 artifacts from Java interfaces to SessionBeans and EntityBeans and value holders, to JSP, to SQL. If one is not already a J2EE expert, there is no way he/she can make sense out of these artifacts so they can add the rest of the logic.

    There are several people I know that are using VE with no Java background (let alone J2EE), and no SQL or HTML/JavaScript/JSP experience. This is one of the primary goals behind VE. It makes a great difference if one of your design goals is to eliminate 100% of the low-level (technology dependent) code, vs. the 70-30 rule that the MDA architecture encourages (not forces) you to aim for.

    Yes, you can build applications without this type of technology...developers are already doing this today, however, on the expense of more required skill sets (smaller number of qualified developers), more hand-written code (open for human error), longer development cycles (an order-of-magnitude longer), larger development team sizes (greater chance of project failure), and smaller number of web/business applications that are platform neutral (one of the great disadvantages of Linux compared to Windows).

    I still encourage you to download the technology and use it for yourself. The online demo shows the points I'm making, but we've been in this business so long that we are all very skeptical of demos.
  21. Future SE[ Go to top ]

    You're right in that raising the level of abstraction, especially via visual

    >models, is nothing new. The history of software engineering is full of failed
    >attempts. However, you have to keep an open mind that one day, one technology
    >will break through this barrier and succeed in delivering on the promise. I
    >happened to believe this technology is VE, but again, I'm a little bias:-)

    Much as I admire your new technological solution, as well as your personal convictions, I tend to think that, unfortunately, you're barking up the wrong tree. Even if your solution turns out to be the most perfect one so far, I wouldn't be able to convince myself that it would make one iota of a difference in my world.

    I really hate to rain on your parade like this, as I'm sure you're more than excited with your beautiful shiny tool, but the real issues in software are not in the implementation arena. That's not where we're losing money and burning resources. Consequently, we're not really interested in improving that area. It's kind of OK as it already is, warts and all (although we're aware it's not nearly as good as it should be, we have nevertheless a bigger fish to fry).

    If, on the other hand, you came to me with a solution that would help me capture software requirements better, and would help me design the solution (on the conceptual level) faster and in a more reliable fashion, then I'd sit up, pay attention, and would fight tooth and nail to get those approvals from my upper management/stakeholders for the hundreds of thousands/millions of dollars rolling.

    I think it's time for the world of software developers/solution providers to wake up and realize that implementation is NOT where the bottleneck resides. If we establish that things are that way, why bang your head against the wall, wondering why your solution is not being widely adopted? Why not shift your focus, identify real bottlenecks, and provide sensible solutions that we, the consumers, would be more than happy to pay for?

    In short, a word for the vendors/open source project visionaries out there: stop pushing those lame implementational solutions on us!

    >Back to the specific point you made, unlike most of the MDA tools that generate
    >an obscene amount of code for every domain object--code like you said that you
    >have to understand in order to complete, VE doesn't generate any code.

    It's not the question of whether the tool generates any code or not. The bottom dollar question is very simple -- can the tool/platform deliver the solution as needed? If it can, who cares about the underlying code, or about the lack of it thereof.

    Let me illustrate this with a very simple example: some 10 years ago I worked in a large company where the home grown solutions were developed using IMB's mainframe (AS/400) with a CASE tool (Synon) installed on top of it. Now, for those of you who don't know, AS/400 is the so-called 'business machine', an appliance built strictly for hosting/serving business applications (unlike 'general purpose' Unix/Wintel boxes). Thus, it is very streamlined, extremely tightly integrated, and extremely simplified. It comes with a built in job control, logging, transaction, security, everything. Consequently, it is much, much easier to build a CASE tool for such a simplistic environment.

    The problem was, all those CASE-based solutions could only be developed so far. Inevitably, there always arose a situation where the tool just couldn't deliver, and the developers had to roll up their sleeves and produce a hand coded solution using the good old Cobol.

    Now, once you start mixing CASE-produced solutions with hand coded ones, the can of worms gets opened, and sooner or later, the developers will get frustrated, and will (unilateraly) decide to re-write everything in Cobol, or any other language of their choice. So, you see, the end result is that you basically duplicate the effort.

    I've never seen a tool-based shop that hadn't undergone this runaway curve, from a neatly disciplined practise where they were using the tool 100%, to the disarray of having a mismatch of tool-based and handcoded apps. Not a pretty sight.

    The lesson we've learned is that there's nothing wrong with Cobol/Java/C etc. Eventually, no matter what approach one takes, everything will end up back to the production of the low-level code. Same goes for HTML, Javascript, etc.

    Anyone who hires developers who don't know those low level technologies is asking for trouble. You cannot possibly run a serious real life IT shop with people who know nothing about HTML, jsp, C++, or Java, etc. A tool/wizard of any kind will not get you real far in that respect. You may think you'll be using the tool to expedite the development, but in the end, you'll pay the double price, when you find your developers re-writing all those wonderfull apps.

    >There are several people I know that are using VE with no Java background (let
    >alone J2EE), and no SQL or HTML/JavaScript/JSP experience. This is one of the
    >primary goals behind VE. It makes a great difference if one of your design
    >goals is to eliminate 100% of the low-level (technology dependent) code, vs.
    >the 70-30 rule that the MDA architecture encourages (not forces) you to aim
    >for.

    I'd be really amazed if you ever manage to eliminate 100% of the low-level code. The people you've mentioned who are using VE without knowing the underlying technology are probably good only for developing toy-sized apps. Put them in any 'baptism by fire' situation, and they'll melt like an ice cream cone in the sun. You cannot survive the grind of developing and implementing a real life, high volume software app without understanding the underlying technology. It's very much like building a house -- on paper, everything looks so neat and straightforward, but when push comes to shove, there's a lot of know-how that only a very experienced masons/carpenters are able to pull off and deliver an acceptable edifice.

    And these know-how guys cost money!

    >Yes, you can build applications without this type of technology...developers
    >are already doing this today, however, on the expense of more required skill
    >sets (smaller number of qualified developers), more hand-written code (open for
    >human error), longer development cycles (an order-of-magnitude longer), larger
    >development team sizes (greater chance of project failure), and smaller number
    >of web/business applications that are platform neutral (one of the great
    >disadvantages of Linux compared to Windows).

    I know you mean well, and that you have good intentions... but you see, the above is a 'pusher' talk. Yes, you are stating the obvious. It is true that it costs money to build a decent software application. It is also true that there is a risk of human error associated with the endeavor of building an app. But, so what? If you want to get anything solid, it's gonna cost you.

    Why would I all of a sudden feel compelled to buy a bottle of snake oil, and foolishly believe that I can now get something good for nothing? I'm aware that it is costly to build solid apps, but you know what -- that the way the cookie crumbles. Are you all of a sudden promising that, if we use your tool, everything will automatically become dirt cheap, while at the same time improving in quality manifold? See, it's this pusher's sales pitch that I'm having trouble accepting. Sounds too much like Microsoft to me.

    >I still encourage you to download the technology and use it for yourself. The
    >online demo shows the points I'm making, but we've been in this business so
    >long that we are all very skeptical of demos.

    I'm not skeptical of demos. I've been in this business long enough to be qualified to see through smoke and mirrors. I'm not saying that your demo's got anything wrong, or that it's trying to hide anything. All I'm saying is, even in the best case scenario, if we accept that everything you claim in there is absolutely correct, that still wouldn't address nor solve our pressing problems.

    Thanks for this opportunity to review and discuss your intriguing solution.

    Alex
  22. Future SE[ Go to top ]

    You bring a lot of points, some philosophical that I would rather not debate (after all, a lot of it is deeply ingrained in our personality and belief system), and technical ones that I will take a stab at answering.

    As far as wide-scale adoption, it is a result of many factors, "software pushing" ability of a giant like Microsoft is one of them, but it is not the main one. By the end of the day, the value proposition and business value are the deciding factor. Developers didn't leave assembly in favor of 3GLs (for a large percentage of development), or 3GLs in favor of 4GLs (for most of the leading business applications) because they were pushed into it, but because it made a good business sense. Then there is the fact that some developers will take pride in reinventing the wheel writing low-level code while their counterpart are accomplishing the same thing with a push of a button for only so long. After all, no matter what personality type one is, it is a matter of evolution and progress.

    Going to your implementation not being the bottleneck, I will have to disagree with you for two reasons, a direct one and indirect one. Historically, a good rule of thumb is that implementation is about one-third of the development effort of software. I believe this increased significantly in the last decade or so with the addition of a multitude of technologies and required skills ranging from GUI development, to web development, to the evolution of technologies and architectures that enable large-scale distributed computing. Accordingly, reducing the development time and effort of implementation has a direct impact on the overall development time and effort of a software project.

    The indirect impact falls under three categories: reducing the implementation time, effort, and additional required skills, also reduces the requirement gathering and analysis time, and the design time. If you can quickly turn a requirement or a concept into a concrete manifestation that you can show your domain expert (or user) for validation, you can cut down a lot of wasted time on hypotheticals and miscommunication, and reduce the degree of formalism required in your software development process without jeopardizing quality. After all, this is the premise behind a lot of agile software development processes (iterative, XP, etc.), and the argument for prototyping.

    The second indirect impact is the required team size and the project management overhead. We all know that throwing more bodies on the problem doesn't reduce the overall development time. There are a lot of studies that show that going beyond a certain team size increases the overall development time because of communication overhead and personality conflicts. Even breaking your development into several teams has significant communication and project management overhead that creates a natural breakpoint. Accordingly, reducing the implementation effort and required skills reduces your team size which further magnifies the overall reduction in development time.

    Last, but not least, is whenever you use frameworks (or automation tools), you reduce the human error rate and accordingly the required testing and debugging time, while you improve the overall quality. I can go into more details, but I know I'll be preaching to the choir.

    That means if you're able to do a 2-week implementation in 2 days, you're not cutting the development work of a 1-month project to 17 days, but more likely to less than a week. That might be compelling enough value proposition to trigger wide-scale adoption.

    As far as the successes and failures of CASE-based projects, it is a mixed bag. The fact that there is no wide-scale adoption of CASE tools is not just because of technical shortcomings but also because of business models (e.g. pricing) and overall technology evolution and availability (e.g. most were targeted toward mainframe and not every one of us has a mainframe in their backyard). Sticking with the technical side of the discussion, as I mentioned in previous posting in this thread, there are a lot of lessons learned and advancement in software engineering concepts, practices, standardization, architectures and technologies that raises the overall chances of success today.

    As far as VE's approach (btw thank you for the "excited with your beautiful shiny tool"...I've been in the business long enough and covered so many technologies and development experiences that I'm not religious about any given technology, language or vendor--even Microsoft;-)...it is my desire to improve and expand the overall quality of life in general, and mature software engineering into a true engineering discipline in particular, is what excites me), it's really simple and doesn't differ too much from many OO languages at the basic level. Meaning, you can create objects' static structures, add behavior with support to the common types of flow-of-control constructs (if-then-else, looping, etc.), use core OO principles (e.g. inheritance, polymorphism, etc.), and access a rich core-library (in addition to Java's) to express your desired logic. So, theoretically, there is no domain logic that you can do in Java, that you will not be able to express in VE (in far less statements). However, VE shines in the area of separating, and streamlining the development of (and in many case automating) the interface logic/code like user-interface, database, existing apps, and the underlying runtime container/VM (e.g. web/app server). It's far easier to write a set of stand-alone Java classes to do something, taking input from the command shell arguments (or System.in), and spitting the results to the System.out, than to develop the same logic but make it accessible via a GUI interface or a web browser, then make it store/retrieve data from a database. What VE does is make that later part as small and trivial as possible, so your focus is on the core (domain) logic.

    That said, VE is no silver bullet nor it is applicable to all types of software development. I started my first posting encouraging people to categorize software instead of lumping them under one umbrella. For business/web type applications, VE raises the abstraction-level and hence reduces development time, effort, and the number of required skills. Even within this category, there are cases where VE might not be appropriate. If the bulk of your logic is algorithms or AI, for example, and very little is interface, then VE might be an over kill. If your app has a mixed bag, then you can use VE as your overall environment, which runs on top of J2EE, then plug in your algorithms written in Java (or anything else that you can access from Java), and use it as a black-box (or as a third-party library), maintaining complete separation in tools, skills, etc.

    I think we can all agree that raising the level of abstraction in software development above code is inevitable. It is a matter of when, how, and who will be on board. If you don't keep an open mind, then you will miss being a contributing voice to it. If this doesn't affect your business, career, or any aspect of your life, then none of this maters--lucky you. To the rest of us, this will continue to consume brain cycles:-) man...and I said I will not get into the philosophical points:-)
  23. Accelerating the mistake-making process[ Go to top ]

    As far as wide-scale adoption, it is a result of many factors, "software

    >pushing" ability of a giant like Microsoft is one of them, but it is not the
    >main one. By the end of the day, the value proposition and business value are
    >the deciding factor.

    I have serious doubts that this is the case. You make it sound as if business people/executive types are the ones responsible for the wide-scale adoption of software platforms/products. That's simply not the case. Software industry is a field created and run by propeller heads for propeller heads. Same as accounting is the field created and run by bean counters for bean counters.

    But more importantly, you haven't addressed my most pressing issue -- what's the use in improving the implementation practices if the thing implemented is useless? It's like that old saying: "computers tend to help us in making mistakes much, much quicker". In your case, high quality implementation tools help us implement lousy specifications much quicker.

    Imagine a hypothetical situation where traditional architecture (dealing with real life buildings) was underdeveloped. The architects would be producing unsounds blueprints, and the construction industry would be expected to implement those. The end result would be buildings that are crooked, unsafe, disastrous. Seeing the magnitude of the crisis, people would naturally jump at fixing it. But, instead of fixing the blueprints, imagine if people went on to invent more powerful tools. So now, instead of taking two years to complete that crooked building, you will need only one month. That way, you'll be empowered to see the horrible result much, much quicker (thanks to the agile construction methodology), and would be able to react to it in a reduced time.

    Would that be the best approach to fixing the problem? I don't think so. So why are you advocating similar approach to building software edifices?

    Why do we see advantages in building crooked software edifices in a reduced time frame? Why build them at all? What's the use of having those agile methodologies, if, sooner or later, we're gonna end up with a crooked product anyway?

    What I propose instead is to focus on not allowing lousy blueprints to enter the picture in the first place. And you gotta admit that your tool has nothing to do with the blueprints.

    You are also forgetting one critically important ingredient that changes the entire dynamics of software development -- shipping the implementational projects offshore. It is incomparably cheaper for us to outsource the implementation offshore than to retrain our existing staff in using the shiny new tools. The cost of living in third world countries is much smaller than the cost of living in North America/Europe, and consequently the implementors can be attracted with much more modest compensation packages.

    Alex
  24. Accelerating the mistake-making process[ Go to top ]

    <quote>
    But more importantly, you haven't addressed my most pressing issue -- what's the use in improving the implementation practices if the thing implemented is useless? It's like that old saying: "computers tend to help us in making mistakes much, much quicker". In your case, high quality implementation tools help us implement lousy specifications much quicker.
    </quote>

    I thought I answered this very point, but I will take one last stab at it.

    The core principle behind agile development is to surface any miscommunication in the requirements as early in the development process as possible. Depending on the specific process that is being used--some people use prototyping, storyboards, limited implementations, etc., the goal is to get the requirement in a concrete enough form so they can be validated with domain experts and/or end-users before spending significant amount of time (and money) in low-level design and implementation. The requirements are usually broken down into small units of work and an iterative process is followed to transform each unit of work into a concrete form. Feedback is gathered at the end of each iteration and the necessary adjustment are made moving forward.

    If you can use a technology that enables you to quickly get to a concrete implementation (not throw away prototype or limited implementation), then you can reduce the iteration duration or increase the scope of each iteration, hence reduce the overall development time while ensuring that you're building the right software (vs. "useless implementation"). In a matter of fact, I had several experiences with using VE in real time with domain experts, understanding their requirements, white boarding the use cases and domain objects, implementing the models in VE, and getting the experts validation right in the same conference room. In one case, we spent a little less than a week, and developed an application that they had hard time expressing its requirements before. Granted it was a small application, but this process has nothing to do with the size of the application.

    Your focus on getting the requirements right is the correct focus. The point I'm trying to make is that using technologies that expedite the low-level design and implementation activity and reduces the number of required skills (empowering a wider range of users to do the implementation), has a significant impact on getting the requirements right and reducing the cost of discovering a requirement bug late in the development process. Gathering requirements is a manual step and open for miscommunication. The only way to eliminate miscommunication is to close the loop and present a concrete form (as a running software, not more text documents or visual models) to the domain experts for validation. Reducing the turn-around time from gathering to validating is the most effective way to make sure you're building the right software, and is the subject of many software development processes.

    And last, but not least, shipping the implementation work abroad (outsourcing), has many shortcomings, not the least is the same point you're making with building useless software. If developers working right next door to the domain experts and speak the same language are ending up with "useless implementation" because of poor requirements. What do you think adding several thousand miles, at least one large body of water, and some language barriers would do? Also, using more (and cheaper) bodies never scales long term and will continue to be the barrier to progress until you automate some of the activities. After all, automation is software's greatest contribution to other industries…isn't logical for the software industry to benefit from this same automation?

    With these notes I resign from this thread:-) Catch you guys on another topic.
  25. Business skills are not useless. They're not useless to the IT developer of today and certainly won't be in the future. I think in the past, the majority of I.T. developers have thought in terms of IT skills when looking for jobs/assignments. When I changed jobs last, 3 years ago, I (foolishly) didn't give much thought to the industry I was inteviewing for (insurance, pharma, etc.). I looked at it purely from an IT skills standpoint. Going forward, I think you're going to see developers with an intimate understanding of 1-2 industries,and their going to stay in these areas. This business knowledge/experience is going to be of higher value than the particular programming background.

    Also, I've never suggested that programming skills are of no importance but I believe they will become lessimportant down the road.

    The main reason for the diminishing relevance of programming skills will be tools which will allow you to develop applications easier. Building a J2EE system is far too complex today and that will change, eventually. And yes even those not in the coveted top '10%' of programmers will be able to develop solid apps meeting user satisfaction. I've seen posts in other thread knocking vb-developers because they're not as technically savvy or don't understand all of the internals behind the scenes. These posters failed to realize that, to virtually everyone but a few tech-elitists, that this is a good thing. It means that business can have quality apps in a smaller amount of time, developed by either cheaper programmers or personnel who are not in fact programmers at all.

    I admit that these tools are not quite there yet but they will be - on that I'm certain.

    Mike
  26. The core principle behind agile development is to surface any miscommunication in the requirements as early in the development process as possible.

    That's what RAD is. Could it be that Agile is just a newer name for RAD?
  27. Accelerating the mistake-making process[ Go to top ]

    This is funny. Although you've said in your post:

    "Your focus on getting the requirements right is the correct focus."

    that didn't prevent you from saying:

    "The core principle behind agile development is to surface any miscommunication in the requirements as early in the development process as possible."

    Now, if you agree with me that focusing on getting the requirements right is the correct thing to do, why do you think that we need agile development in order to reveal any miscommunication in the requirement? Shouldn't a proper focus on getting the requirements right suffice?

    It's like saying that we should instigate proper airport security, and at the same time not forget to every now and then beat the hell out of passengers, just in case they may have some devious plans. Shouldn't a proper security system be sufficient? Or, if it isn't sufficient, why even bother setting it up in the first place?

    Alex
  28. Future SE[ Go to top ]

    If, on the other hand, you came to me with a solution that would help me capture software requirements better, and would help me design the solution (on the conceptual level) faster and in a more reliable fashion, then I'd sit up, pay attention, and...

    UML is a modeling language. Do you know the difference between an analysis model and a design model? There are CASE tools dedicated to capturing analysis models and then applying automated design.

    Now, once you start mixing CASE-produced solutions with hand coded ones, the can of worms gets opened, and sooner or later, the developers will get frustrated, and will (unilateraly) decide to re-write everything...

    This hasn't been my experience, and I doubt the success stories in CASE vendor literature conclude as you say.

    The lesson we've learned is that there's nothing wrong with Cobol/Java/C etc.

    What's wrong with Java is that it's too low level. It doesn't provide enough abstraction to empower an analyst. This drags on R&D.

    I'd be really amazed if you ever manage to eliminate 100% of the low-level code. The people you've mentioned who are using VE without knowing the underlying technology are probably good only for developing toy-sized apps.

    Sun's JRE classes have native methods. Does this mean Java is a failure? Does this mean the average Java developer must know C++?

    I'm aware that it is costly to build solid apps, but you know what -- that the way the cookie crumbles.

    Last week Steve Balmer (Microsoft's CEO) noted that the average Amerikan programmer is paid $75K yearly. He predicted that mandatory offshoring will achieve a market equilibrium programmer salary of $50K yearly. Are you promising us stable worth if we remain strictly J2EE hackers? Are you ready to accept Balmer's predicted 33% pay cut, or will you maintain your current wage by increasing your value to a shop's R&D pipeline. I'm talking about personal growth, not code monkeying. Do you agree that business analysis skills will matter more than they did during the "if you build it, they will come" dot com boom?

    Are you all of a sudden promising that...

    What are *you* promising us? Presumably nothing.
  29. Future SE[ Go to top ]

    Last week Steve Balmer (Microsoft's CEO) noted that the average Amerikan programmer is paid $75K yearly. He predicted that mandatory offshoring will achieve a market equilibrium programmer salary of $50K yearly. Are you promising us stable worth if we remain strictly J2EE hackers? Are you ready to accept Balmer's predicted 33% pay cut, or will you maintain your current wage by increasing your value to a shop's R&D pipeline. I'm talking about personal growth, not code monkeying. Do you agree that business analysis skills will matter more than they did during the "if you build it, they will come" dot com boom?


    I hadn't heard that statistic before...glad you pointed out.
    I'd venture to say it's believable. The outlook for I.T. folks has changed so dramatically in the past 5 years that it's astonishing. Who would have thought, back in '98, they couldn't make a nice, cushy living as a programmer in the U.S. 'til retirement?

    I've heard many IT colleagues say they'd never tell their kids to choose a cs major. And that's funny as I remember seeing a quote from Ballmer himself, only a month or so ago, saying that he didn't see enough American kids choosing I.T. That might seem to contradict the previous statistic (50k avg. salary), but I don't think so. I think the point is that the field of I.T. is bright but only for those who recognize that programming skills will continue to become the least valuable skills in your arsenal (and probably the least used),and work to develop business skills.

    Mike
  30. Develop which business skills?[ Go to top ]

    I think the point is that the field of I.T. is bright but only for those who

    >recognize that programming skills will continue to become the least valuable
    >skills in your arsenal (and probably the least used),and work to develop
    >business skills.

    You are absolutely right in stating that programming skills are becoming the least valuable aspect of one's IT portfolio. However, you are quite off in stating that developing business skills is where it's at. Sure, if one wants to change careers and switch to business administration, then yes, by all means, one should focus on perfecting one's business skills.

    But for an IT person, business skills are useless. They only serve to cloudy the picture. There are countless business domains, and dreaming of mastering them all, even at a very superficial level, is strictly insane. If that's the case, which business skills should you develop? You, as an IT specialist, may be called in to any number of specific business situations. Are you to be expected to know each of those business domains inside out? Of course not -- that would be humanly impossible.

    So, the only approach that makes sense is to develop one's technical skills, if one is to stick with the IT industry.

    I don't know where did this 'develop your business skills' myth come from? Nowadays, everyone seems to be parroting that mantra, but it absolutely makes no sense. It's almost like saying that a doctor cannot cure a patient unless he knows everything about that patient's history, education, plans for the future, aspirations, and so on.

    Alex
  31. Develop which business skills?[ Go to top ]

    \Alex B\
    You are absolutely right in stating that programming skills are becoming the least valuable aspect of one's IT portfolio.
    \Alex B\

    What a load of hooey. Programming skills are your basics, if you can't program well you can't program well :-) This is like saying knowing how to use weapons is no longer very important to an army, and thus armies should have a lower focus on weapons use than information management, logistics, and strategy. Sounds nice, until you find that your privates are whizzes at driving a computer but don't know how to turn off the safeties on their guns.

    The basics of any profession are always the most important pieces to them. Abstractions away from the basics are refinements on how to put your basic skills to the most practical use. Armies and corporations have learned this lesson over and over again - advanced concepts are useless if you don't know the nuts and bolts.

        -Mike
  32. Develop which business skills?[ Go to top ]

    Armies and corporations have learned this lesson over and over again - advanced concepts are useless if you don't know the nuts and bolts.

    But that isn't so. A C developer needn't know CPU condition flags, and a Java developer needn't know addressable memory. The limit of software abstraction is subject to ongoing revision.
  33. Future SE[ Go to top ]

    ...Steve Balmer (Microsoft's CEO) noted that the average Amerikan programmer is paid $75K yearly. He predicted that mandatory offshoring will achieve a market equilibrium programmer salary of $50K yearly.

    Full story here.
  34. Which business skills?[ Go to top ]

    UML is a modeling language. Do you know the difference between an analysis

    >model and a design model? There are CASE tools dedicated to capturing analysis
    >models and then applying automated design.

    Judging from the appaling state of the majority of the software apps I've seen so far, those CASE tools dedicated to capturing analysis models appear to be broken.

    >What's wrong with Java is that it's too low level. It doesn't provide enough
    >abstraction to empower an analyst. This drags on R&D.

    For people who don't know how to use object oriented technology, Java may appear to be too low level. For people who are well versed in OO, Java is an extremely high level conceptual tool.

    >Sun's JRE classes have native methods. Does this mean Java is a failure? Does
    >this mean the average Java developer must know C++?

    In a sentence before this one, you've claimed that Java is too low level. Now, all of a sudden, you claim that Java is too high level, and that maybe average Java developers must know C++ in order to grasp the native methods. Can't you make up your mind and stick to it?

    >Do you agree that business analysis skills will matter more than they did
    >during the "if you build it, they will come" dot com boom?

    The question is: which business skills? There are countless business skills, related to countless business domains. A person can become an expert in payroll, or HR, or accounting, or construction, or mining, or forestry, or health care, or banking, or retail, etc., etc. but no person on earth can become skillful in all those areas. So, which would you pick?

    >What are *you* promising us? Presumably nothing.

    Not so fast, big guy! You're presuming to much, apparently.

    Here is what I promise: I promise you, that if you shift your attention from the software implementation activities to the activities of understanding the business GOALS, the software products you finally deliver will be hundred times better and more usefull than they are now.

    Alex
  35. Future SE[ Go to top ]

    <quote>
    The code for the dynamic behavior, however, must be completely technology and architecture independent, representing the domain logic in the purest form. For example, if your code references a ResultSet, a Connection, an InputStream, JNDI Context, or a ServletResponse, then this is not the code I'm referring to.

    In addition, if you're using Java as is (especially pre JDK 1.5), which is a 3GL, then you're not using to most descriptive and appropriate language for capturing domain logic for business or web applications. Having to deal with iterators, primitive wrapper classes, explicit casting, and anonymous inner classes as a block closure, as a few examples, is a complete (and unnecessary) distraction.
    </quote>

    In this part I choose the pragmatic way:
    There is no (not yet) standard way to use a 4GL to define the dynamic behaviour/sequential flow. ABAP/4 for example is a 4GL but it's only on SAP world. OK, you can use state + activity diagram (petri net) + OCL + whatever from OMG as they become more formal. But as you said before, it's easier to use text-based code and I agree with this. Therefore it's not a bad idea to stick with 3GL like Java or C# or whatever languages to express the dynamic behaviour. In this case it's not a problem at all to use ResultSet, Connection, InputStream, JNDI, etc. if you use Java. The 3GL Java will also evolve and you will see that there will be a lot more things happen in this language => easier, more high level, etc.

    Cheers,
    Lofi.
  36. Future SE[ Go to top ]

    But as you said before, it's easier to use text-based code and I agree with this.

    Are you aware of Prograph, a flow diagram notation for algorithms? Its most common praise is that it's easier than text scripting. And the visual feedback during debugging is unrivaled.
  37. Future SE Prograph[ Go to top ]

    <quote>
    Are you aware of Prograph, a flow diagram notation for algorithms? Its most common praise is that it's easier than text scripting. And the visual feedback during debugging is unrivaled.
    </quote>

    No, and thanks for naming it. Is Prograph standardized?

    But as there are many learning types: see (visual), hear (audio), feel and experience, etc. I'm a type for reading a text in algorithms ;-) You also have the standard debugger in your Java text ;-)

    Cheers,
    Lofi.
  38. Opinion: The End of the Beginning?[ Go to top ]

    The classical understanding of evolution is that it can be observed as history but not in progress. This doesn't apply to the software market, since it evolves in Internet time. I actually watch the software market change. I get so absorded in today's complexity that sometimes it's difficult to predict change. But economic fundamentals are constant. There's always selective pressure to reduce R&D cost and to recoup it earlier. So automation is a natural goal.

    Few things are as easy to automate as the manipulation of logical content, such as software algorithms. With automation the cost saving from increased productivity can be passed to consumers. Model governance accelerates the iterative development cycle and reduces defects. Developers then get time to add more features. Consumers get a higher quality product. MDA is here to stay.
  39. Opinion: The End of the Beginning?[ Go to top ]

    Twelve years ago, just when I started my Computer Sciences degree, everybody talked about the same things that Mr. Hitchens reflects in his article. Some of the most unfortunate 'prophecies' of that time were:

    1) 'Secuential programming is obsolete, and parallel programming will make the hardware developers to change the physical architectures of the computers'. Today we are still using x86 architectures...
    2) 'Internet is only for research or universities, we cannot find a business model for a free network'. I still remember this phrase from a conference of a VIP from 'Telefonica de España'... may be he signed later on for a Internet start up!!!
    3) 'The future of the spanish engineers is in URSS, because they are good in sciences, but not good enough in engineering'. This assertion came from the Dean of the Computer Science Faculty of the Politechnic University of Madrid... a real visionary!

    Nobody knows the future, and forecasting is complicated, as I have shown above. Mr. Hitchens is not describing the future, he is just describing the present, the present of this miserable economic cycle.

    Happy new year folks
    Diego
  40. Two worlds...[ Go to top ]

    I think there are going to be two worlds for IT guys.

    The Application world where you dont really write a lot of code . You get away from Programming and focus more visual representations. Rely on Tools and you get paid for your tool knowledge and Business domain knowledge.

    The Other world will be the Tool builder world. The folks that actually write some code. The tools for these "tool builders" are going to be programming languages. These guys will be affected by fundamental changes in programming concepts like AOP .

    So you gotta choose the world you belong to.

    This is happening even right now. The Division between the two worlds at present is there but there is still an overlap of skills requirement because the tools are not there yet. The overlap is going to althemore decrease.

    A business developer is left to do these tasks at present
    1. Understand and Document the business
    2. Master an existing framework (will be replaced by a Visual tool in the future)
    2. follow an architecture and code Business Objects.(and hopefully build a Domain model).( mostly scripting and modelling)

    The activities required for a business developer does not necessarily expect him to know about behind the scenes concepts.
  41. Two worlds...[ Go to top ]

    I think there are going to be two worlds for IT guys.

    >
    > The Application world where you dont really write a lot of code . You get away from Programming and focus more visual representations. Rely on Tools and you get paid for your tool knowledge and Business domain knowledge.
    >
    > The Other world will be the Tool builder world. The folks that actually write some code. The tools for these "tool builders" are going to be programming languages. These guys will be affected by fundamental changes in programming concepts like AOP .
    >
    > So you gotta choose the world you belong to.
    >
    > This is happening even right now. The Division between the two worlds at present is there but there is still an overlap of skills requirement because the tools are not there yet. The overlap is going to althemore decrease.
    >
    > A business developer is left to do these tasks at present
    > 1. Understand and Document the business
    > 2. Master an existing framework (will be replaced by a Visual tool in the future)
    > 2. follow an architecture and code Business Objects.(and hopefully build a Domain model).( mostly scripting and modelling)
    >
    > The activities required for a business developer does not necessarily expect him to know about behind the scenes concepts.

    My sentiments exactly. I remember reading a book when I started in IT, back in the early 90's. Talking about the coming day when you will just drag and drop objects and voila - your complete application. Obviously this hasn't happened but the book described exactly what you mentioned - 2 sets of future developers - 'application' developers and 'system' developers, doing the tasks you've described. I believe this is indeed what we'll happen.

    As far as building quality apps in a reasonable amount of time, we've taken a step back since the web-era began. Tools like Oracle Designer, etc. weren't/aren't perfect but you could build something of quality, and on-time. We need such tools for building n-tier apps. The developer of a web-based, J2EE-based Insurance app shouldn't have to deal with Struts, or even JSP for that matter. Rather, this developer will use a tool which utilizes these technologies.

    Many developers enjoy working with such low-level constructs when building business apps(and benefit in many ways from all the complexity) but the business-types have had it with, too many failed projects, taking too long.

    I think we eventually will have to decide which developer camp we want to be in. And, as for me, I'm reaching the decision that it's better to be anchored more on the business side of things, with some technical understanding. Building these tools will be done off-shore, where labor/skills are cheap.

    Mike
  42. Two worlds...[ Go to top ]

    Industry Observer: I think there are going to be two worlds for IT guys. The Application world where you dont really write a lot of code. You get away from Programming and focus more visual representations. Rely on Tools and you get paid for your tool knowledge and Business domain knowledge. The Other world will be the Tool builder world. The folks that actually write some code.

    Michael: I think we eventually will have to decide which developer camp we want to be in. And, as for me, I'm reaching the decision that it's better to be anchored more on the business side of things, with some technical understanding. Building these tools will be done off-shore, where labor/skills are cheap.

    I came to the same conclusion, and I made the same choice, but for a different reason: job satisfaction. I'm happiest with abstractions, diagrams, and governance. I think the dichotomy you both described is only a temporary one. Ultimately tools are merely applications, and therefore amenable to the same generative automation. A model compiler can be generated by a model compiler in much the same way that Sun uses javac to build itself. Dog food!
  43. even more than two worlds[ Go to top ]

    There is (and will continue to evolve) the role of application developers vs. tools developers, but let's not forget the embedded systems developers, the gaming developers, the operating systems developers, etc. Each one of these categories requires different skill sets, specialization, and programming tools.

    I agree with your observation, but sense a little trivializing of the role or required skills of application developers. If things evolve in the right direction, then application developers would not be measured by their tool knowledge, but by their modeling skills. Taking a business scenario (or operation), deciding what to automate, then creating (analysis, design, and testing) the software applications to automate these activities take advanced software engineering and problem-solving skills. Combine this with either existing domain expertise or the ability to quickly learn new domains and understand their inter-working, and you have what it takes to be a good application developer.

    I apologize if I'm reading too much into your posting. But, some of these opinions are common toward VisualBasic and other RAD developers. To some extent, with the lack of standardization and the focus on proprietary wizards and GUI tools, it is/was more about tool knowledge. However, with the evolution of model-driven development standards (like MDA), and the adoption of such technologies for rapidly building business applications, the focus will shift from tools knowledge to good software engineering and problem-solving skills.

    Hope you guys have a happy new year.
  44. Two worlds...[ Go to top ]

    There is (and will continue to evolve) the role of application developers vs. tools developers, but let's not forget the embedded systems developers, the gaming developers, the operating systems developers, etc. Each one of these categories requires different skill sets, specialization, and programming tools.

    >

    exactly , a gaming developer in my context is a business application developer. His Business : understands gaming applications . his toolset . Gaming Toolsets that he has been using in the past. I dont think CGI(computer generated imagery) developers understand anything with java or programming . They understand movies and in general converting human faces to digital faces.

    What is probably going to have in the future is that you will get Insurance developers / or Banking developers. who understand the Insurance / Banking world quite in detail. This is presently more of a Business Analyst role. The BA presently is not that skilled in building application. With the advances in the modelling world they will contribute more to actual task of construction.
  45. exactly , a gaming developer in my context is a business application developer. His Business : understands gaming applications . his toolset . Gaming Toolsets that he has been using in the past. I dont think CGI(computer generated imagery) developers understand anything with java or programming . They understand movies and in general converting human faces to digital faces.

    >


    A CG developer has to understand many things. Particle physics (to model the smoke and flames), or body movement, or the way that hair swishes. That I guess is their domain knowledge (of course ultimately they have to defer the approval of the effect to the real Domain Experts - the director and producer). Then they have to understand a programming language enough to transform this knowledge into a plug-in for their CG system so that their users (the designers and animators working in the film) can utilise their software. So they do need to understand a programming language of some kind.
  46. Two worlds...[ Go to top ]

    "So you gotta choose the world you belong to. This is happening even right now."

    This is happening right now, but there are a lot more than two worlds. There are so many software development disiplins that a VB coder doesn't have any idea what an OS device driver developer even does and vice versa.

    The face is, as progress is made in our field, more and more layers of abstraction are built, and more still are built on top of those. That's not a problem. Yes, less skill and experience required to get something done, but the need for intelligent people is not going away.

    There is alwayse going to be a need for intelligent people.
  47. Traditional programming activity (as kind of mental activity) is becoming smaller and smaller part software development. Of course, you can not make good software without programming skills, but the time you spend on programming is less for each new project.

    For example, after 10 similar software projects, if you spend same time on programming in first and tenth project, then you are not very good programmer. Just scale this example on whole software industry with tool vendors, open solutions, extendable applications, etc.

    When you have last time coded sort algorithm, design search data structure, etc? Customer’s trouble reports become pure business scenarios.

    But importance of a skill and time spend on activities that is based on the skill is not proportional. So, programming skills are steel important, but focus is moving from one set of skills to the other.

    Programmers will always build system based on exact rules, limited resources and do it in some formal language (text based or not). The system will solve real world problem based on many not very exact rules and evaluated by user who knows nothing on underlying technology.

    The core programmer task is to understand real word, some formal system with technical limitations, and to match those two.

    The exact/formal part will become more abstract, more mathematical, and real world will be more and more covered by different tools and platforms.

    Nebojsa
  48. Technocrates Future[ Go to top ]

    Agreed: I think in future there will be drag and drog nothing else. NOw a software developer should also know about the all business. Future is bright for technocrates.
  49. Technocrates Future[ Go to top ]

    Agreed: I think in future there will be drag and drop nothing else. Now a software developer should also know about the all business. Future is bright for technocrates.
  50. If you are so sure that the end of the era is here, then what technology has emerged to replace it?

    Try using a visually-oriented tool like Rational Rose or Together-J. On any complex project (like the one I'm on which has over 6,000 types in it), those tools will melt down, not just physically, as in the graphics modules can't scale to that level, but idiomatically.

    I remember a story once of a developer like me on a Rational Rose project where he opened up the system's UML representation and got a huge, green spider-web of lines and boxes that were almost useless. He spent an hour rearranging all those boxes so it was "readable". What did it end up looking like? I think the phrase he used was "a big green doughnut".

    You wanna program using a big green doughnut as your metaphor? We got a ways to go before any nontrivial system will surpass what we've got going now.
  51. Opinion: The End of the Beginning?[ Go to top ]

    This will not end era of programmers. It will again to some extent change meaning of the word 'programmer' Software engineering as other engineering disciplines tries to simplify itself. And there is nothing with a smell ?end of era? in that. If future trends discussed in this article achieved it will lead us to significant growth of software developer community and growth of importance of software in real world. That?s why biggest companies pay so much attention to tools for developers now. Only question is how fast those future trends will become true?
  52. Future SE II[ Go to top ]

    I also wait for:

    - A common and standard way to define cartridges in MDA. Reusable, extensible and component-based cartridges (AndroMDA, b+m-Framework, ArcStyler, etc.)
    - A common and standard way to define Aspects in Java (AspectJ, HyperJ, etc.)

    Gee, I hope we are going to see this happens ;-)

    Cheers,
    Lofi.
  53. Future SE II[ Go to top ]

    I also wait for:
    - A common and standard way to define cartridges in MDA.


    A XSLT stylesheet is inherently a standardized generative cartridge that can be plugged into many existing rival processors, such as Saxon, Xalan, etc. OMG poses QVT as a natural evolution of MDA. The only QVT implementation I know of uses XSLT. I wonder if anyone would even consider doing QVT without XSLT.