Before, during, and after The PDC there was plenty of talk about Model-Driven Development bringing about the obsolescence of "the developer" as we know it today. Many people are saying that because of tools like Oslo making Model Driven Development easier, "business people" will be writing applications via modeling tools instead of coders writing code.
Assuming they deliver on all their promises in the final release, is Oslo going to change the world and make the role of the developer obsolete?
No. And then some filler text which really just says that, no, it won't. This promise has been around just about forever. Business people aren't good at modeling their processes. And it might be find for forward-only thinking, but when things have to change, or modifications have to be made - it won't be easy.
no, no, 1024 times no.
every shiny new tool makes this claim, from CASE tools to 'expert systems' to WYSIWYG editors, to 'visual languages', and they're always wrong - for fundamental reasons: writing software is a difficult creative process.
in this case if business people understood things well enough to define a complete model, they would already be programmers ;-)
The answer is in the essay No Silver Bullet. In summary, no.
You can also read the Wikipedia article.
No sometimes there are just some things that the normal business man cannot create. He may know what he wants but does not know how he wants to do it or see it displayed. Therefore, developers will always be needed
Oh Lord, no. Now show me a CPU with 2 billions cores, interconnected with gray moveable bits and I'd get a bit worried. Change the way we do your job? Perhaps. It will change with or without Oslo.
You forgot the "subjective" tag.
I cannot count the number of times that a family member, friend or well meaning acquaintance has suggested to me that development is a dead end career choice. They hear all of the media hype from insert-company-name-here that touts their ground breaking technology that will put the development of software into the hands of business people. The fact is that over the years software development has become easier, but the problems we are solving has become more difficult and challenging.
We no longer have to twiddle bits to get a machine to do what we want it to do. That is the job of assembly language. We no longer have to write assembly language for a specific piece of hardware. That is the job of the operating system hardware abstraction layer. I could continue, but the point is that we continually make our jobs easier, but at the same time find harder problems to solve.
I am reminded of an episode of ST-TNG where Jordy LaForge is setting up a holodeck simulation and just asks the computer to setup a simulation with varying parameters. It struck me that although the computer could quickly “write the code” for the simulation, it still took a technical engineer to know how to direct the computer. I know it is a fictional example, but it still demonstrates my point. Technical engineers will always be needed to help the non-technical people solve problems with computers/machines.
Many people are saying that because of tools like Oslo making Model Driven Development >easier, "business people" will be writing applications via modeling tools instead of >coders writing code.
Everyone that has developed for "Business People" knows that the developer will never be obsolete. Maybe the developer as we know it today and in terms of "writing code" but software applications won't be "clicked together" anytime soon.
Despite the best efforts by the finest people, we as programmers and developers have yet to put ourselves out of a job.
Just haven't managed to stumble upon it.
In a similar light, the finest medications, salves, creams, herbs, and any of the other cornucopia of remedies available at the drugstore do not make us doctors. With casual reading, we are still spectacularly underqualified to self medicate all but the most base maladies. First Aid and advanced First Responder training is about as far as the layman can really go in terms of being an effective "practitioner" of medicine.
For when it comes down to it, the human body is vastly complicated.
Similar with computers. No matter the colors of the boxes, or the thickness of the lines, or how many icons are on the design palette, dragging lines and connecting boxes do not make someone a programmer.
I am a great advocate for end user empowerment, in all fields. I love seeing the amazing things the "untrained" users can come up with in tools such as Excel (the most popular end user programming tool on planet), Access, etc. They do amazing things. Or the truly Rube Goldberg like scripting environs that rise from that festering swamp we know as "Computer Operations and Administration". Incredible things, and I applaud it all. I applaud every success.
But the fundamental problem, the part of the puzzle these systems can NOT solve is this single basic fact: all of these things run on a computer. And computers are some of the nastiest creatures ever created. Some folks "get" computers, others not so much. But whether you "get" them or not, computers stay computers. Harsh, nasty, and cruel.
It takes a wild animal trainer to train a wild animal. They may allow you to pet the big orange kitty, it may see soft and furry and snuggly. But be sure, when someone lets you do that, there is someone else nearby that understands that animal, and they likely have a gun with them because they know that animal.
Programmers, good programmers, know the animal that lives within the computer. We're the ones with the guns.
We're not going anywhere.
Also, who would maintain and enhance Oslo if not "developers"?
Seriously, each time there is a great new development paradigm, a shift occurs which allows more programming-challenged users to move up a notch in productivity, and at the same time creates a vacuum at the top which sucks in the best developers. So the developers get shifted -- never obsoleted.
COBOL was supposed to enable business people to write code themselves, way back when. That plan didn't work out very well.
"They" have been trying for years to develop modeling tools and the problem with them all has been three-fold:
We need these attempts at modeling tools even though they fall short because they are driving progress forward, and that's a good thing, but we're a long, long time away from seeing them render "programmers" (as we currently know it) extinct.
Modeling tools in a way are attempts to allow those who lack programming knowledge BUT have an abundance of application/business domain knowledge to design their own programs. As a member of the software development community myself, WE would really serve ourselves better by becoming more knowledgeable in whatever business domain we're working in and push solutions upwards, rather than having managers use tools to push solutions downwards when we know those solutions will be wrong.
If we can bridge the gap between having the software knowledge and the business knowledge to know HOW to solve business problems, then that's where the sweet spot is - and where the money is to be made!
No. In real life, business people are already writing applications. It's called Excel. And when it breaks, or gets too large, they ask for a programmer
Interesting article on Oslo in Fowlers blog. Having DSL support that enables biz people to manage rules in a very high level and specialized language is very powerful concept.
Did C make assembler programmers obsolete? Did C# make C programmers obsolete?
It's still about programming, just on a different abstraction level. You won't find an appropriate schema and runtime for every business problem.
You won't find a schema that makes our work of transforming thoughts into excecutables obsolete.
The work of the programmer is simple. The work of a designer is not. If we create programs that can turn designs into code, less programming is needed. I mean, what programs are more than algorithms and structures? Everything else is just frameworks, which can be considered as elements that are not needed to be programmed when they are injected into the code automatically by the framework and by design guidelines.
Sounds like this makes the assumption that business people are capable of distilling nebulous business rules into logical self-consistent sets of orthogonal logical statements.
Most business people aren't very good at logic... Those that are make good developers ;)
Seriously, I've had to work with visual basic written by business people. Just because they CAN write VB, doesn't mean they SHOULD write VB. :) Being able to take general requirements and distill them down into logical sets of rules is a skill that shouldn't be taken for granted. It's unlikely that any software/AI/tool/whatever will be able to do this as well as a human for the foreseeable future.
Yes. Oslo is going to shut down all of the developer shops in the world. I plan to take up crafting, open up a store on etsy, and sell socks with skulls sewn on.
I remember when yahoo pipes killed the mashup market since anyone in the world could now do their own mashup in graphical form without any programming. You remember that, right?
Computers are named after a job that humans used to do: computing.
Each development like this just means that humans get to work on more and more interesting unsolved problems, instead of solving the same problems over and over again.
My new interesting problem will be figuring out the world's coolest socks. Unless someone really needs me to help them with some of this computering stuff.
Okay, having never heard of Oslo before, I had to do some research on what Oslo is, or will be allegedly... and here are my thoughts:
Didn't Microsoft already try this concept with Access? And where exactly do we stand with that again? In addition... wasn't this the reason Visual Basic was originally invented? And ask the general programming community as a whole how they feel about VB... compare notes. Sure Oslo might show some promise... just as Access did, but given the history of these tools, I just see it as the next potential bain of my life, further ensuring job security, but at the same time making me want to kill myself [or more likely someone else] because yet another badly designed/written application that should never have made it out of development into the wild now requires maintenance - by me. My view of these tools is this:
They're the greatest thing to happen to us because there's no end of screwed up software that we get to fix and maintain, thus ensuring that we will be employed forever more...
They're the worst thing to happen to us because there's no end of screwed up software that we get to fix and maintain, thus ensuring that we will be employed forever more...
The biggest question is - will Oslo enforce well optimized, well performing, well written, maintainable, scalable applications for use across an real enterprise environment or [more likely] will they [like Access] just provide some creative control giving more tinkerers the ability to develop some marginally useful small scale tools that will ultimately be used for a purpose they had no hope of and no business being used for...thus enabling them to call themselves "software developers".
How on earth could someone who learns to program using such a tool possibly have a solid grasp of basic programming concepts? The first time they need to do something complicated and it all blows up in their face. So now you have more hiring problems because you have these self proclaimed "developers" showing up for interviews that at best can't write a function to complete a basic Euler task or at worst have never even heard of Euler.
I doubt very much that Oslo will have any hope of replacing well trained, well educated, insightful, visionary developers. How can it? Unless Microsoft has made some headway on designing an artificially intelligent tool that can figure out exactly you need (rather than what you think you need), optimize your processes and produce a piece of software that does it all for you... unlikely.
My advice - if you need a real application developed, hire a programmer, if you need a basic hack tool that will make some of your tasks easier, use a tool like this to throw something together, allow your co-workers to use it if you must. Don't have the lack of foresight to expect it to function on the level of a well thought out, well developed, well tested enterprise level application.
Well, well.
Ok. Software Development will not disappear. Software Developers also not. Clear. However how many of you are still doing assembler? So it will change.
Not merely by Oslo. Oslo can only be a means, a vehicle for a new level of achievements in model driven development and architecture. Just as other vehicles. Yes, there are pros - there are also cons about Oslo as a vehicle. But the MDD and MDA train will not stop.
Yes, there will be more code generation - more generic code in frameworks, interpreting the declarative models. There will be more governance and higher quality as a result of having these models that the runtime is aware of.
There is still a lot to do about which DSL we would need for which area. But it is not that we are starting from scratch. Look at all that OMG has. Look at BPMN for example. Powerful.
So first DSL will make the lifes of dev organizations healthier, because they can 1) work more effectively 2) establish governance and thereby increase quality. Later the Business People will make additions to the models. Of yourse a dev activity will follwow, but better integrated tools will make the task easier and more effective. It may in some casese be even so easy and effective, that it can be done soley by the business people. Given that some patterns have been prepared by the developers - or should I better say by the architects and engineers.
The type of job will change. The tools will become better (I am primarily talking about MDA and MDD in general) - of which Olso is one. The work will become more effective and some of it will be done by Business People only.
Well, seeing how DSL Tools started taking about 10-15% of my total development time, I'd say that DSL-related tech won't replace programmers completely, but it will certainly leave its mark on the software development landscape.
uh. no. At minimum, the tech support industry will thrive with every new Microsoft technology...because, it will be buggy, missing critical features, and have a large extensibility ecosystem.
Let's not forget, model-drive development has been around a very long time. And, many verticals/apps won't even apply to what Oslo is doing.
Oslo is really a way to protect Microsoft proprietary interests.
In "Eliminating The Programmer", Scott Westfall had this to say:
Programmers think more logically. Working through if-then-else conditions is a core capability for any programmer.
Programmers have a superior ability to analyze problems and come up with solutions. They excel at analyzing preconditions, sequences of events, and outcomes.
Another key ability where programmers typically have an edge is the ability to make order out of chaos. I think that’s because the programmer is responsible for creating order within the program. We break systems into subsystems, subsystems into modules, and modules into units. There are no physical constraints that dictate the structure of the solution.
Let’s say that someone does manage to write a tool that allows people to define software and control its behavior without having to write code. The person using this tool will still need all of the other mental abilities of a programmer. If this were to happen, we haven’t eliminated the programmer; we just changed the job description a little.
The one main thought I've had with model driven development (or anything that claims it will put developers out of a job) is this: it seems to me that in order to get it to do exactly what you want, you would have to define your model (or tweak the transform engine) so explicitly that you might as well write the code anyway.
If there wasn't some inherent value in what the professional developer does, all of the development jobs would have been sent overseas already. Someone has to take it from concept to technical solution, and all of that cannot be automated by a tool.
We may have to change the way we do things, such as not getting bogged down as much in lower level technical problems, but there will always need to be someone who makes the machine dance.
When true strong AI is solved and a computer can infer meaning and deal with ambiguity sufficient to pass a Turing test and then turn around and crack jokes about the lame questions in the test, programmers will be able to be eliminated.
Until then, no tool will be smart enough to close the gap between mortal and machine.