Slashdot Mirror
Software Tools of the Future
An anonymous reader writes "What are the sofware tools of the future going to be? It's an interesting question, with many facets. Here are some important trends in design and construction tool strategy, which will effect the kinds of software tools that will be delivered in the future. It looks at how to improve software development efficiency through visual modeling, generating code from abstract models, and systematic reuse."
To affectively effect the future of software tools, the obvious support must come from the developers, but the obvious support for developers are their sponsors.
At least three of the five points are almost directly targeting at the sponsors, i.e. PHB and friends.
They don't see(care) if a particular system/software/whatever is most powerful, flexible or easy to use, they're looking at things from the business point of view, e.g. which one brings more profit in the next xx years, and which tool they can easily pretend to understand.
So a tool that's business-"sense"-driven, transparent and offers lower TCO is likely to be more favorable.
Rock that crushes, Paper & Scissors that don't matter.
This article, is simply looking at the obvious research efforts on currently used techniques... It has no vision about what might be done entirely differently. It doesn't even consider the potential of things like using different programming paradigms like functional programming or graph programming.
Bob
0. Alan is a Distinguished Engineer at IBM Rational
translates to: Buy Rational Rose - scaratch that see 5... Rent Rational Rose
1. Connecting business with IT: Business-driven development
translates to: What do you mean that it will take 8 weeks to rewrite? We are already selling the service, you must change it tonight or be fired.
2. Greater transparency in the software development process: Auditing, traceability, and accountability
translates to: We must find some one else to blame, because we don't need to test the part, the system drew it that way.
3. RAD using new programming models
translate to: do not design first. build it first , then find out if it mets the need. Wait that is why the want to find someone else to blame it on.
4. Collaboration among individuals and teams
translates to: Talk to each other. Stop work in the castles with moats that where built between managers!
5. "Pay-per-use" software tools: New licensing and subscription offerings
translate to: We need more money, so we are following M$ model, charge for everything at least twice. Remember: give away the razor, sell the razor blades. Wait that is what Lexmark is doing now.
I develop in Java, and my environment consists of Emacs and Ant, mostly (hardcore, right?). I work with people who use NetBeans and Eclipse, and they keep running into weird problems interfacing them with CVS, or with mysterious classloading "features" that they have, or other obscure problems. Invariably, they don't know how to fix the problems, and I can't help because I never run into them.
I would like tools of the future to be as transparent as possible, to prevent this sort of situation. If tools are so magical that their users don't know the real theory and practice behind them, they end up relying on them to do any work. Their flexibility is very limited, and the tools end up compounding or obfuscating the "real" issues facing them.
Tools will make it easier to hire and fire programmers (and outsource for them), and they'll give middle management more control (or at least marketed that way.) Whoopee! What a Brave New World!
...and being a developer is a (mentally) tricky job, and all the crutches you can lay your hands on are useful to have if they improve your quality and/or productivity.
However you have to be a master of the tool, rather than its slave unsure of how it does its magical stuff.
I've never really got why the die-hards hate any sort of automation in their environments. Why? I understand you want the direct grip on the code... which is exactly what you get in something like Eclipse (well, you have to tell it your source dirs and your classpath, otherwise you can use it as just a text editor with syntax colouring, if that's what you really want).
There are days as a Java dev when a good tool is absolutely worth its weight in gold. For instance, if you're in maintenace mode on a large codebase which you know nothing about, and you change a method's behaviour, what upstream code will that affect? Ctrl+Alt+H in Eclipse will tell you. A text editor which doesn't actually understand the structure of your code would require you to do a lot of fumbling around and regexp searching and cross fingers you're not missing anything.
Pay-per-use implies a secure authentication mechanism, which then opens the door for abuse of one sort or another. If you are developing a product which will compete against something Microsoft already does (or plans to do), and MS gets wind of it, will there be "technical problems" in contacting the authorization server the next time you start up VC++? What about the SCO v. IBM debacle? SCO claimed they could terminate IBM's license for AIX, and if pay-per-use had been in place, SCO could have flipped a switch on all IBM's customers. Do you think that would have affected IBM's willingness to settle? Yes, they could have got a court order to turn it back on, but how many customers would have been down for a day or two, and said, "Screw this, I'm buying my unix from the people who OWN it!"
Pay-per-use is NOT the wave of the future so long as I have any say in it. When my boss asks me for tool evaluations, I'll always favour the least-encumbered tool. And yes, that means even if it's sub-optimal. We can always make changes to F/OSS stuff to meet our needs, and the freedom to do so, IMHO, more than makes up for the extra work involved.
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
Hist first item shows a fundamental problem right off. I've dealt with projects that were driven directly off the business requirements. The problem is that they were driven directly off the business requirements. The next project was for a slightly different set of business requirements, and because they were slightly different none of the work on the first project could readily be transferred over. By contrast in other projects I managed to divorce the business requirements from the actual work, and I could step back and instead of addressing the business requirements create tools and facilities that I could then use to address the business requirements. The next project in that line, with it's slightly different requirements, required only some relatively easy extensions to the existing work and we were in business. It took a fraction of the time. Most of the problems with business-process-driven software design and development, IMHO, is that it's too focused on the end result to be good at front-loading the solving of meta-problems that can speed up later work because solving the meta-problem doesn't provide any immediate advantages for the problem immediately to hand. In mathematical terms, it looks for a local maxima at the expense of an even better global maxima that's on the other side of a minima.
His second item about auditability also aims at the wrong point. When, for example, designing the control software for an ABS system, the goal is to have it work correctly. All else, auditability, certifications and such, are supposed to be means to insure the goal is met. That implies that you judge their usefulness not on their own but on how well they help meet that goal. He's aiming at those things as goals in themselves. ISO 9000 falls into the same trap: it concerns how well you followed a process and not how the final results turned out. This is useful if someone at the top has their eye constantly on the final result and is willing to boot the process out regardless of how thoroughly it complies with ISO 9000 if the end results aren't meeting spec, but all too often the process becomes the goal and a shield against actually being judged on the end results.
When I was younger, my brother and I we're responsible for shoveling show out of the driveway. We lived near Chicago at the time, and survived a couple of blizzards and other examples of Midwestern winters through the sixties and seventies. One year (1977, I think), after removing a four or five foot thick layer of drifted snow from the driveway and front walk, we asked our father if he would consider buying a snowblower. His response was, "Why? I already have two."
We never did get that snowblower.
The higher the technology, the sharper that two-edged sword.
I agree. Anyone who doesn't understand the importance of abstractions is likely to get left behind.
There was a time when you planned to work for your company until retirement, your company had ONE computer, and you used a small set of tools plus technology-neutral algorithmic and domain knowledge to write software.
These days the diversity of technologies that matter is mind boggling. If you don't use something at your employer this month, you'll need it at your next employer next month.
Getting the XML right, getting the HTTP protocol right, etc., etc., involves using tools that automate a lot of things for you. (Libraries are included in what I'm calling "tools".) You just don't have the time or the mental bandwidth to use all of these things quickly and well if you insist on doing everything manually.
IDEs that organize the protocols, handshaking, and plumbing between technologies, that fill in the blanks for you with valid information, that bring the right documentation to you at the moment you need it, that give you one-click builds and deployment, that give you debugging views in every increasing variety, etc., are only going to increase in importance.
I'm with the grandfather poster when it comes to my desire to have tools so simple that you know what's happening when things go wrong. When I can, I use them. But, more and more, it's becoming impossible to do so.
It's just like my father, who mourns the loss of cars with engines so simple and transparent in function that normal people could repair them. For cars, that time has past, and software is going that way, too.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I played with OCaml for a good length of time, considering whether to make it my next language for everyday use. I should also preface things by mentioning that I'm into graphics and rendering; I need fairly heavy duty numeric performance. I've also been thinking a lot about what would be my perfect language, so this has been on my mind of late - I've been reading up on Programming Language Theory papers and texts and contemplating drafting my own language spec and trying to bootstrap a compiler.
.Net framework have a really nice model for FFI.
OCaml annoys me slightly because it seems so tantalizingly close to what I'm looking for but falls just short. For one, I wish it had better support for generative programing. Sure, for template like stuff you can immitate that to some extent through the polymorphism, but because it has to be generic, it still doesn't work out performance-wise. Look at the kind of stuff they can do with Blitz++. And I know there's Camlp4 and MetaOCaml, but they're really too kludgy for my taste, though still better than the insanity that is C++ template metaprogramming. (Ick!) The model that I really like is the macro systems in Lisp or Scheme. That would require a Lisp-like syntax to work, but I'm cool with that.
The other thing that bugs me a bit is that the compiler seems fairly simple in regards to optimization passes. When I've looked at assembly output from it, even with all optimizations turned on, I was surprised to see that it doesn't seem to do common subexpression elimination or strength reduction, like a common C compiler could do for you. I realize that OCaml is more functional, which constrains the compiler a bit, but there are compilers for other functional languages that manage to do flow graph analysis and optimization. (e.g. Stalin for Scheme) This lack is dissapointing in a higher level, more declarative style language like OCaml.
Finally, one other thing is that while the foreign-function interface to C is better than many other functional languages, I wish it were still better. With OCaml, it seems like you'd still need a small library in C as a shim to interface between the two languages. It would be nice if you could simply declare a function's signature, mark it as an external C function and link the library in. To deal with garbage collection, I'd borrow something like the "pin" construction from C#. I think C# and the
Of course, if you don't need such heavy duty performance, OCaml's still a great system and a fair sight better than many other functional language systems. But it's not a panacea for everything.
One more thing: if you use (X)Emacs, be sure to have a look at Tuareg Mode.
There's one thing no one's mentioning. A good development environment needs a good CLI. Despite all the gooey this, and the gooey that. Text is still the interface used. What's that your typing in? A picture you say? Green screen environments have shown us that one can be productive.
Many of the newer code generation tools are very flexible and have some ability to preserve changes to the code; making them easier to fit into real development cycles.
The way I look at it, there's only one good kind of code generator: the kind whose output I almost never look at and never, ever tweak. Compilers, for example, are a kind of code generator that I love.
The other kind of code generator strikes me as just half implemented. Somebody has come up with some sort of interesting abstraction, but they haven't pushed it as far as a service, library, or compiler that you can use happily. These days I never use them.
What's the difference? Maintenance cost. A code generator produces a lot of code that is, pretty much by definition uninteresting. That means that you've hidden the actual interesting code in a whole mess of boring code, which makes it really expensive to maintain. And generally the generated code is highly duplicative, meaning if you want to change certain things, you have to change them in a lot of places.
To me, it seems like code generators dramatically worsen the cost-of-change curve. For any project where you aren't already planning to throw out the code, this strikes me as a mistake.
I actually work with RoseRT on a daily basis and it is the only member of the Rose family that does not suck. Most important reason: complete code generation from model, and model based debugging.
Once you've gone through the learning curve, you become very productive. Mind you, there are always shortcomings. Parallel development and subsequent merges can be a pain because merging is not as visual (e.g model based) an experience as normal development.
Still, the whole package is actually very good. Must have something to do with the fact that Rational bought it (it was first called ObjecTime) instead of creating it from the ground up. Most of their other tools are a nightmare to work with. Ah well, every litter needs a price puppy.
One group at work proudly used the Rational tools to generate some code - it was the most obscure code I had ever seen
Somebody will probably have already said it, but generally code generation is a sign that your language or abstractions are not powerful enough. Code generation takes a more compact form of information and creates a less compact result (generated code). One should use the more compact form to tell the software how to operate, not turn it into bloated code. It is almost like turning a table in a database into a bunch of set/get classes that just echo attributes. That is reverse abstraction. The only justification is perhaps performance, but you are sacrifacing maintainability and simplicity in the process. It is to make the machine happy, not people.
Table-ized A.I.
I see they're still trying to replace the programmer after thirty years. This is nothing new folks. Let me explain the situation. The people running businesses hate programmers. Maybe it's because we have real degrees instead of MBAs, or maybe it's just because we didn't join the right fraternities. But they just don't like us. So they keep trying to come up with ways to fire all the programmers.
It all started with Cobol, the language that didn't need a degree to use. In more modern times it was Visual Basic, the language that even monkeys could use. You've got entire programming environments where all you do is drag and drop stuff around the screen. Rational [sic] salesmen claim you can generate your entire application from UML.
For some generic "fill in the blank" type applications, they're correct. For maybe half (wild ass guess) of applications out there all you need is to wire a form into a database. But what about the other half of applications? And what about the remaining 90% of software that is NOT an application?
At the core of Google is a Damned Big(tm) database, but does anyone in their right mind think Google could ever have gotten off the ground without real programmers writing real code in a real language? Or what about the Linux kernel? Does anyone think it could have been created with a CASE tool? Is there anything in GNOME, KDE or Mozilla that could have been automatically generated from UML? Would you feel safe driving a car which had an ignition system written in Visual Basic?
Programmers aren't goin to go away, no matter how advanced the tools become. They'll make the programmers' jobs easier, but they won't replace them.
Don't blame me, I didn't vote for either of them!
-
The importance of understanding the business context for IT investment has never been more obvious than it is today. More organizations are recognizing the role of IT as a determining factor in the efficiency of their operations, and a bottleneck in their ability to innovate. I am spending a lot of time with customers who want to explore business alternatives, drive IT projects more directly from business needs with well established business goals and ROI, choreograph services to realize their business processes, and monitor those services in execution to relate operations to the needs of the business. Support for that flow (in its myriad variations) is essential. As we use the current generation of tools in this context we are seeing the emergence of new roles, usage scenarios, and support needs. The lessons from this work are leading to a complete refactoring of tooling capabilities.
Let's try that again, in a different context.-
The importance of understanding the business context for office furnishing investment has never been more obvious than it is today. More organizations are recognizing the role of office furnishings as a determining factor in the efficiency of their operations, and a bottleneck in their ability to innovate. I am spending a lot of time with customers who want to explore business alternatives, drive office furnishing projects more directly from business needs with well established business goals and ROI, choreograph services to realize their business processes, and monitor those services in execution to relate operations to the needs of the business. Support for that flow (in its myriad variations) is essential. As we use the current generation of tools in this context we are seeing the emergence of new roles, usage scenarios, and support needs. The lessons from this work are leading to a complete refactoring of tooling capabilities.
See? It's a totally generic statement.A developer is basically somebody, that closes the semantic gap between the idea as it is presend in the human mind thinks and the code that has to be interpreted by the machine. A good tool is a tool, the reduces the burden of this process, so that more complex ideas can be realized.
Of course, not everybody has yet understood this simple fact, e.g. I frequently call him Linus "writing kernel code should not be simple" Torvalds in casual Linux design problem discussions.
But yet more problematic is the fact, that we have not really (yet?) understood, how the process works. Do you know how a program to be is initialially represented in your mind, before you start decomposing it into modules and even smaller parts drawing from learned knowledge and books which algorithms to apply and which techniques to use? I surely don't ... the same way I do not actually know, how my brain composes a series of strange markings on a surface in to legible text.
Yes, neuro-psychology has made progress in understanding the inner workings of the human brain, but they are far from knowing how it really works.
But the worst part: Software designers and exspecially programmers have a long history of ignoring scientific progress, not only in their own area of expertise, but even more concerning other sciences.
All of the discoveries in natural language programm have been deliberatly ignored by newer languages such as C#. And languages like PHP and Perl are even inconsistent from a pure computer scientists point of view.
There are things, I would like to see:
- easy design of self-learning user-interfaces
- real natural language programming
- globalized object stores
- ...
but most of these things are just not going to happen.Either because somebody is to traditionalist about something or simply because clean, simple, standardized interfaces are definitely not what you get with such a heavily divers and varying area like current in-the-field programming.