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."

Comments

Trend vs Financial Backing

[fembots]

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.

Completely lacking vision

[beelsebob]

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

Make it simple

[jackb_guppy]

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.

Re:Make it simple

[Tablizer]

Your viewpoint sounds like Extreme Programming (XP) philosophy. I generally disagree with it. One can design pretty close to needs if given enough time to study the problem.

Good designers can pull it off. The problem is that fad-chasing buzzword-oriented Bozo's usually create giant messes because they are using dogma instead of brains to build software. Perhaps XP is for bad designers, but not every designer is bad.

And, XP is expensive because it reinvents a lot of small wheels along the way that a good analyst can usually filter out up front. Experience can be used to avoid organicly found dead-ends. Creationsim is faster than evolution.

XP also requires the customer to be on-site most of the time, which is probably impossible and unnecessary. If they have enough time to hang out with developers all day, then their tasks probably don't really need automating to begin with.

Are tools a crutch?

[K.B.Zod]

I worry about the increasing power and complexity of IDEs in particular. While they do so much more for developers and have all sorts of whiz-bang features, I bet much of the time the developers themselves don't understand what is going on. They become tied to the IDE, and need it to do all these things because they don't know how to do it "themselves", i.e., without hand-holding.

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.

Re:Are tools a crutch?

[m50d]

Increasing abstraction is necessarily the way of things. When assembly language was invented, some said it was a crutch for people who couldn't write machine code properly. Ditto for fortran and assembly, ditto for garbage collection, ditto for any feature that makes coding easier.

The next wave is the ides that make the repetitive coding unnecessary. Sure, it makes things slower, but it makes *developing* them faster, and machines are getting faster but developers aren't. I don't think there's anything to be afraid of.

Re:Are tools a crutch?

[lostguy]

I develop in Java, and my environment consists of Emacs and Ant, mostly (hardcore, right?).

Not to be snotty (oh, come on, this is /., so I'll have to snot this up a bit.) but you're probably using a tiny subset of the language if you're relying on your understanding of the SDK. You're probably wasting a lot of time trying to remember if it's put() or add() or addElement(), all things your IDE should tell you, and you shouldn't need to store in your brain.

The people I've worked with who insist on using vi or emacs for Java dev work are usually working about 50% or less the speed of people using a quality IDE such as IDEA or VisualAge/Java. Class and method completion alone speed up programming and also expose you to a lot more of the API than you can reasonably expect to hold in your head, especially with the speed at which the SDK has been increasing lately.

Without IDEs, people usually know two data structures, Vector and Hashtable, and the myriad classes in the Collections API are more of a novelty than anything else. If they know more than two collections, they know the non-reentrant versions of each of the above two classes.

I've also watched some of those holdouts switch from emacs to IDEA, and it's truly a "holy shit" moment. You're doing yourself a professional disservice not to be using them.

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.

At some point, you need to give up and assume that an abstraction is opaque. Otherwise, you'll be stuck at a relatively low level in terms of what you'll be able to do in life.

Our entire society has advanced at the same rate with which we have lost touch with the more concrete necessities of survival. The people of ten thousand or so years ago were not appreciably "dumber" than we are. What they did lack was a lot of knowledge, especially of the abstract. They knew, however, which berries were edible and which weren't, how to avoid getting eaten by bears or rabid chipmunks, how to avoid freezing without the use of an electric heater, etc.

These are all things we've had to give up over the millennia on our way to an advanced civilisation. In the future, we will have to give up more.

Almost all people writing object oriented software don't really need to know about electron tunnelling and capacitance. They may need to know about garbage collection, but usually only when something goes wrong in their application. That usually happens once or twice a year, but not on a daily basis, and not for much longer. The entire purpose of the virtual machine is abstracting away a lot of the lower level details -- and this is a good thing!

I think it's useful to be able to write trivial programs in a primitive tool such as emacs/JDEE. However, I can all but guarantee that you can do it faster and with a much higher quality with a real IDE.

Exactly, tools are a crutch...

[Anonymous Coward]

...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 - Bah!

[crimethinker]

I can't quite understand why all the salesweasels think we'll jump at pay-per-use licensing. Here's a thought: I'd like to BUY my tools and OWN them, not be treated like a criminal by a vendor.

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

Fundamental problems in the items

[Todd Knarr]

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.

Left behind

[GCP]

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.

Still trying to replace the programmer

[Brandybuck]

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.