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.
emacs
Gosh, these are tools of the future but I have already found several job openings asking for 5 years experience in each tool...
94% of Repubs and 21% of Dems voted to renew the Patriot Act
Good code generators. Yeah, and AI that works too. And flying cars. Utopia is always around the corner. Oh, wait. We have code generators - in India.
I'm less interested in the new directions dev tools can take, and more interested in getting the good parts of existing tools more ubiquitous. MS tools (like the .NET Dev Studio) are very nicely created, with flexibility and convenience. I would like to see tools with the same capability for C on Linux.
.NET programming like they poo-pood VB programming... but part of the reason for their popularity is the quality of their development tools. Bring some of those enhancements over to C on an alternate platform, and I think the results would be quite interesting.
A lot of developers poo-poo
Raven
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
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.
thats a fact, Rational tools in my experience are way over-repesented - One group at work proudly used the Rational tools to generate some code - it was the most obscure code I had ever seen - it was not even clear what half the modules did or were suppose to do. They gave me an executable to take to a subcontractor and try out - the subcontractor laughed at it (and so did I...) There is no escaping these tools, we just need to minimize the wasted time they cause... IMHO
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.
Additionally, I have found it quite buggy when running it on Solaris and Redhat based systems at school where i've primarily used it. I shouldn't have to delete my workspace directory just to get it to run as I have needed to.
These issues need to be resolved before it can be considered seriously.
Checking out my form of escapism.
I've already seen one post dissing code generators, but I expect to see that general class of software development tool to greatly increase in popularity over the next couple of years...
Why? Well mostly because they are getting better. 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. Also we are already seeing 'just in time' code generation as an optimization tool; that functionality, when combined with runtime environments like the Java Runtime or the CLR, is going to get easier and more powerful.
So, in the end, we may see developers tweaking code generation templates and filling in design forms/creating design diagrams in order to create some classes of software -- business software and game levels would probably benefit greatly from this scenario.
Obviously there are other classes of software development which would see much less benefit...
- -
Are you an SF Fan? Are you a Tru-Fan?
...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.
Here's my set of software predictions. Some more detail to fill in for that other guy's blog entry.
Here we go:
Some links to check out on these topics:
Semantic Designs (makers of a very powerful, generic transformational environment) http://semdesigns.com/
Link to Nic Rouquettes slides from a talk on MDA at the UML 2003 conference) http://ase.arc.nasa.gov/uml03/rouquette.pdf
Link to an article from ACM Computer magazine (last january I think) about MDS, and project at JPL which aims to incorporate some of these ideas into the design of a robust, re-usable flight software platform http://www.computer.org/computer/homepage/0104/Reg an/r1059.pdf
Refactoring Browsers were a radical change 2 years ago, and improved coding immensely.
But the claim that they "aren't commonly used" is bunk. They are in very common use today. Eclipse, IDEA, JBuilder, etc. Java IDES have made a huge leap in the last 2 years, and they rock.
They succeeded because they weren't trying to reinvent programming. They just aim to make coding easier and better.
Why non-Java IDEs haven't caught up, I don't know. The worst part by far of having to deal with C++ is that these days the tool support just isn't up to the standard of Eclipse or IDEA. emacs does great stuff with syntax, but it can't replace an IDE that is tracking the codes semantics and making clever use of that knowledge.
sean
There have been a lot of attemps and experiments since the early 1970's to improve the software development and management process. However, there has not been any magic bullet. Most improvements are incrimental and often disputed.
.NET run-time engine in which different languages compile to the same thing, but perhaps use relational and more declarative techniques instead of the map-based "database" and imperative-intensive approach favored by OOP proponents and languages. OOP is generally a code-centric way of thinking and is not very condusive to DPFM in my opinion. It is a fight that has to be settled one of these days.
Graphical tools have generally proven ineffective because there is no one "proper" viewpoint. All the possible viewpoints needed by different departments or situations cannot fit onto the same sheet of paper or screen without being messier than the coded counterpart.
Another thing the article mentions is getting closer to how the user thinks about things. The problem with this is that everybody thinks differently. There is no one "right" way to think and the variations are wide. Plus, people with different ways of thinking have to use the same software or same information. Delivering different viewpoints of the same info leads to the next item:
One area I would like to see explored more is divorcing presentation from meaning (DPFM). Rather than use linguistical syntax to store algorithms and attributes, if such information was treated more like a database, then one's view of the algorithms and information could be altered to how a given developer or user wants to see it.
It is roughly similar in concept to Microsoft's
Hierarchical approaches to managing such information have generally failed to scale. The real world and its change patterns are not really tree-shaped. Philosophers have known this for quite a while, and computer scientists keep rediscovering it the hard way.
One would be querying info instead of relying on file and code browsers so much. Some things, such as math and Boolean expressions, are still best represented as code (although they don't have to be stored that way under DPFM), but the size of such units can perhaps be reduced, similar to how code is reduced to mostly individual event snippets in event-driven UI systems. But to study event snippets, you query for them if there is no UI click-and-point approach available for a given search.
Yes, all this may take more horsepower, but better abstraction usually does take more.
Table-ized A.I.
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."
Ooh - sorry for responding to myself but I thought up another. It might be nice if there was more security/workflow in a version control system.
One simple example of security might be something simple like - you do not have permission to edit this file. I bet this can already be accomplished with file system permissions and what have you.
But what would be even better would be for the environment to support basic workflow style processes. For example, if Bob is the expert on the Data Access Layer, and you make some changes and check them in, Bob should receive a notification with a note from you and perhaps and automagically generated report detailing what interfaces changed. This same kind of tactic has been employed on some wiki's to reduce vandalism. It could also be implemented as an approval process.
Moving along in that workflow direction, it also might be nice if the development environment was formally aware of the to-do list. In other words, if we bring in more version control functionality, why not add project management integration.
You might start the day by opening a task. Then you edit several files accomplishing the task. The changes you made in the version control system become associated with the task as do a record of the files that were changed. If someone else needs to see what changes you made for a particular task or bug or project, they can drill down from the top instead of trying to figure out what you did by looking at comments in version control.
How about a SQL DB of source code, particularly C/C++? Just tokenized code, not the text of the source. SELECTing code by block inserts whitespace and comments according to user preferences. The compiler SELECTs code for generation, INSERTing large binary objects into other tables, including executables. Configuration options fill other tables. Scope is per block across the entire project, rather than the ancient file scoping paradigm. The entire filesystem granularity of C/C++ is a straitjacket.
Just the whitespace options would make it worthwhile for me. Then there's concurrency of team access, backups, distributed repositories, versioning, redundancy optimization, and all kinds of other better interfaces for the rest of our toolchain. That's the kind of bionic source infrastructure I'd like to see in my future.
--
make install -not war
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!