Slashdot Mirror
Has Software Development Improved?
earnest_deyoung asks: "Twenty-five years ago Frederick Brooks laid out a vision of the future of software engineering in "No Silver Bullet." At the time he thought improvements in the process of software creation were most likely to come from object-oriented programming, of-the-shelf components, rapid prototyping, and cultivation of truly great designers. I've found postings on /. where people tout all sorts of design tools, from languages like Java, Perl, Python, Ruby, and Smalltalk to design aids and processes like UML and eXtreme Programming. I'm in a Computer Science degree program, and I keep wondering what "improvements" over the last quarter century have actually brought progress to the key issue: more quickly and more inexpensively developing software that's more reliable?"
http://cs.ua.edu/407/disc5_frm.htm
There is no silver bullet, never will be.
Logic requires careful thought, and careful thought requires time.
You are being MICROattacked, from various angles, in a SOFT manner.
Not too sure if it an improvement, but I know some people use languages in which programs can be proven to work like ML. Of course if you actually want to write a program which *does* something it is probably not for you.
I can say I honestly don't like Java.
Nowadays we've got great tools like Flash, scripting languages like VB Script, and markup languages like HTML.
Not every programmer these days is a old COBOL nerd, ASM coder, or C junkie.
I yearn for the days when Borland was great. The Turbo C++ and Turbo Pascal products probably got half of the programmers in the 80's, late 90's started.
... has been way more trouble than its worth.
I don't think there are any magic bullets. Software development (unlike most other engineering disciplines) is a build-it-yourself from the ground up everytime experience. Go read http://www.reciprocality.org/Reciprocality/r0/ (mentioned in the past on /.) to see a different view on what makes some folks way more productive than others.
Computers don't boot into a ROM BASIC anymore.
Welcome to termpapers.slashdot.org!
Programs that assist programmers in the development process by handling who changes what when, etc - are - IMHO - a huge improvement.
I seriously doubt that a program like Linux could flourish without programs like CVS.
furthermore - many of the programs that do this sort of thing can be used for any programming language... you could even use it for simple documents.
While I'm only in my mid 20's and I'm no veteran by any stretch, it seems like there have been huge leaps in programmer productivity made possible by things like OOP and off-the-shelf components.
However, I think they're equally balanced out by huger demands on programmers. Once it's realized that a programmer can do 2, 3, or 10 times as much work by using more efficient methods management is quick to pile on 2, 3, or 10 times as much work!
This isn't really unique to programming either. I think it's universally applicable to any area where technology permits greater productivity.
For example, look at all those ads from the 50's. Things like the microwave, the vaccuum, and the dishwasher were supposed to usher in a new era of leisure. Do we have more leisure? No, we have less, as those luxuries become necessities and we cram in more activities in out new-found time in order to stay competitive.
OtakuBooty.com: Smart, funny, sexy nerds.
Probably the biggest improvement is due to the creation of software processes, whether it is the legacy waterfall or the latest XP.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
But seriously, a lot of people develop beneath the "enterprise level" and some of the buzzword concepts just don't scale that well for smaller project.
In my opinion, the two things that have really made a difference are databases (as opposed to manually creating file formats) and the object-oriented paradigm.
My best advice is to use everything with a grain of salt because there is always something "better" on the horizon.
I'm in a Computer Science degree program
If you're in the U.S., GET OUT WHILE YOU STILL CAN - the tech job market (and the economy in general) are in horrible shape. My friends are coming out of college with CS/IS/MIS degrees and finding NOTHING!
And if you stay in CS, may God have mercy on your soul.
If I had a dime for every system I've seen where there was no planning, no logic, just brute force coding I'd be richer than those in the .com era.
This bring me back to the last slash dot post a few weeks ago of the 80 hour a week SW engineer.
True SW architects are hard to find and so is thier logic. A managment that understands the expense and time involved are even rarer entities.
Hardware Architecture keeps building on similar themes, no real inovation going on (I use that term loosely). SW requires a human factor.
more quickly and more inexpensively developing software that's more reliable
Based on the last 20 years either working in or supporting government efforts, I'd say yes. However (there is always a however), it depends on the sophistication of the developing organization. The cowboy shops still suck. Those who have embraced more formal processes have become more reliable. It is a 2-way street though and requires the customer to be more sophisticated as well. It doesn't do a damn thing to have a development shop at CMM-5 if the client doesn't understand the need for process and doesn't understand the software development challenges.
The invention of pencil and paper.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
Of everything that has happened in the last 25 years, I'd say that development of higher level languages have helped the most. Back in 1977 (25 years ago) the best you had was Assembly. Of course, you didn't have anything close to what we now call a PC. In the last decade, I would say that Visual Basic and Python have helped the most. It has allowed programmers to spend less time writing code, by mainly skipping the compile step.
If you look at how programming languages and sofrware evolve, the errors just get higher level. For example, Java keeps you from having memory leaks and buffer overflows. But a bad coder is a bad coder and will write buggy software where the problems are on a different layer. They will just arrange your off-the-shelf components incorrectly. With wherever there is still really low level C/assembly programming stuff going on, off the shelf just really isn't applicable so you still have the really low level pointer arithmetic problems. As time goes on nothing really changes... it just evolves. So our bugs are just evolving.
but HTML and Perl have probably set us back 15-20 years.
What's a sig?
The ability to create decoupled software components , combine them into a coherent, functional application, and deploy them into a standards-based container (i.e., an "application server") is a HUGE step in programmer productivity.
Silver bullets still do not exist. New technologies and methodologies are often hyped as such and naturally fail to live up to the hype. However, that does not mean they are useless.
These technologies and methodologies have allowed us to keep pace with Moore's law. The amount of software we develop today would simply be impossible using the state of the art in 1970. We routinely poor out millions of lines of code in mammoth projects that take sever hundreds or thousands of man-years to complete. The only reason we are able to do so is because of improvements in development methodologies and technology.
The (huge) research field that studies these technologies and approaches is called software engineering.
Jilles
High quality, reliable C and C++ compilers have emerged as defacto standards on major platforms.
Now you wouldn't think of developing on UNIX with anything but GCC and the associated build tools.
In 1990 you were stuck with whatever C compiler your vendor shipped, and there were more than a few dodgy compilers out there. Modern compilers with useful error messages have done more than anything else to make debugging and development faster and easier for me.
The focus has definitely shifted away from algorithms and toward abstraction. This was supposed to make things easier, by letting the software do what it does best and keep track of bookkeeping, while we concentrate on building models and governing interations between them.
Some of it actually makes sense - the object oriented paridigm, component models, virtual machines. (VM's, by the way, go back at least 20 years in the literature -- I studied them in college in the late 80's. However, like Pascal, they were originally considered as an instructional tool, and nobody at the time thought that anyone would be damn fool enough to actually try and *implement* such a thing!)
But just like letting grade-school students use calculators for their arithmetic, I'm not certain these things are best for students. Sure, you get usable code out quickly, but without an understanding of the underlying algorithms and logic. I doubt many modern 'c0derz' could properly knock out a simple quick-sort, let alone a fully ACID SQL DBMS.
"Lawyers are for sucks."
- Doug McKenzie
Not universal, but seems to be pretty prevalent.
If you think about it, in the past 25 years or so, software development has become increasingly more complex. Even though there are many more programming and scripting languages available today, more efficient than the likes of QBasic, regular C, Fortran, Cobol, etc., it really seems like software development tends further away from improvement and more towards diffculty.
Sure, one of the better innovations was the introduction of objects, but rather than drastically improving programming, it seems like it's more useful creating worthless shovelware, as people just repeatedly use objects coded by someone else, maybe add their own source code, and turn out some "software" that is barely usuable.
www.google.com
Now I'm sure that some people out there will rave about how great XP is, but reading the Mythical Man Month and working on any large, or even medium scale project with a long term life-span will tell you that while some elements of XP are good, these are the ones that existed before.
1) Write your test cases up front... this is ages old. XP isn't as rigourous as others who say "and make sure other people write them".
2) Pair Programming, works for two people of equal ability. The two headed surgical team from the Mythical man month is a much more effective way of using two heads.
Basically things like XP sum up how long computing has to go to become an engineering discipline. In every other engineering subject there are critical elements:
Requirements
Design
Testing and approval of design
implementation
testing of implementation (throughout implementation)
Delivery.
Maintainance
For a construction project all of these elements are mapped out well in advance, which is why the construction industry can work on lower margins.
To become better requires not a "Silver Bullet" as Brookes says, the technology won't make the improvement. Its actually about people applying the rules _rather_ than looking for the Silver Bullet. Some projects succeed, others fail, there are reasons for the failures and the successes. But rarely do we learn from either.
XP is the embodyment of the non-engineering approach to computing that pervades this marketplace. The idea that you can build it wrong and change, don't design "code and check", have a unit test written by a bad coder to check his own bad code.
Brookes is right. At the end of the day computing success is down to a realisation of the soft-skills allied to technical talent.
If you have 10 brilliant people leading 100 average people... fire the 100 and support the 10 to do the delivery effectively. Make sure they follow a process, and make sure that the requirements are defined and change as little as possible. Make sure designs are verified, make sure code is reviewed.
Sure its less exciting that "just coding" but in the end it takes less time, costs less to maintain and delivers what the customer wants.
Engineering is a discipline, XP is just glorified hacking, only by becomming disciplined will software improve.
An Eye for an Eye will make the whole world blind - Gandhi
else how would commercial software company's make money ? They need to sell updates and support.
;-)
They code crap. My personal experience with not to big software company's is they like to sell crap if they can and most of the time the other company also sells crap and after wards you dont even own the software you buy. Software bussness sucks atm.
Until the world wakes up and start demanding that software needs to work just like material stuff or else they wont buy it. It wont get better in the near future aslong we except crap from even big company's like Microsoft, which is becoming more reliable and stable but still sells a awful design if you ask me. oke maybe start a flame here but most software is like throw a way dishes instead of a rolce roys. And i think company's like microsoft showed the smaller software houses that its oke to sell crap as long it sells and it bugs me cause software has a bad name, but i know good software exists, bla bla bla, you got me pissed again slashdot....i hate humans
Quazion.
I think the quality of code has always been poor, but it seems
as though most products now ship with bad code and expect the user to
have to download the "latest" version (ie code that actually makes the
product do what you paid for).
In comparison, people yelled and screamed when it was revealed that
certain obscure floating point instructions on the Pentium chip were
off a few decimal places. The worst it did was cause some of those
clipping errors in Quake.
You must be kidding.
Of course it is now easier to create software than before.
First of all, source management software wasnt available 25 years ago. Try creating a huge piece of software without any way to rollback changes, share the same source tree with other developpers, etc... (cvs/sourcesafe/starteam/etc)
Second, profiling tools. Hey, you want to know where that memory leak is? Where that CPU bottleneck is? Pretty hard to do when you were coding in cobol many years ago... Doing the same is way easier now with OptimizeIt and stuff like that.
I could go on and on but I must leave for work =)
IT/APp programming sucks...
:-)
but us system engineers are doing ok, thanks
... hi bingo
I've always believed that one day some bright college kid is going to come up with a completely different style of computer language and interface, and when that happens we will all slap our heads and go "D'oh! So that's how we should be doing it! Obvious!"
Like the web and P2P, the most influential ideas are often quite simple, and "obvious".
Software, the hardware upon which it must run, and the applications which are in demand won't hold still long enough for us to turn software development into an art (or science). As long as we are permitted, even required, to hammer out code as fast as we can, there will be no art and little science in software development. The volumes of info a programmer must master or at least become familiar with continues to increase, exacerbating the problem.
Have you used the Microsoft Visual Studio? It makes your life amazingly easy by finishing your words for you, making it easy to find functions, it gives you hints about what the arguments to each function are. It is all around a great piece of work.
If Perl had an IDE that was as easy to use it would dominate the world. (more than it already does)
NO.
The project management keeps moving the target. The customer still says "I don't know what I really want, but keep coding and I'll let you know when you get it." Analysts can't analyze, designers can't design, coders can't code, testers don't test (enough), ad nauseam.
Methodologies and philosophies of software development can only make up for so much. Sometimes, they are counterproductive. They "lower the bar", leading management to believe that the methodology can fill in for cheaping-out on hiring good developers. But we /.ers know the truth, don't we: Quality software comes only from quality developers--people, not methods or schools of thought or books by really smart people. Since quality developers are rare (like Leonardo DaVinci rare), quality software is correspondingly rare.
Welcome to the Panopticon. Used to be a prison, now it's your home.
Refactoring tools are great. Makes for more clarity in code -> more understanding -> less errors. To bad not to many people know about it where I am.
Off the shelf components have helped a LOT.
perl is ugly to code in, and perl OOP is obviously a hack. I had a graphics/OOP professor who said, "nobody likes to program in perl, but it gets the job done." Obviously he lives in the land of language theory, where perl doesn't, but it gets the idea across...
perl gets the job done because of its massive collection of components.
I think I'd go further to say that the big improvement there is in repositories where you can get massive collections of components, as there have been languages like perl (in terms of having lots of stuff - PL/1 comes to mind) in the past.
Places like CPAN, Sourceforge and Freshmeat really make the difference. So ultimately, the internet is the means through which software development has sped up (at least when you're not talking about RAD-GUI development, which is another thing entirely).
Mod me down and I will become more powerful than you can possibly imagine!
Jolt cola. Anything from the caffeine section at thinkGeek. Humpback notation.
We've impoved the software industry.
As Engineers, we didn't sit around all day debating on whether or not we should got o base-3 computing instead of base-2.
We spent our days solving problems. Also, we learned how to do this in a timely fashion. Get it right the first time, or fail the test because you run out of time.
Engineering discipline.
I've been using CVS for some time now - even bought a _great_book_ to assist me in understanding it better.
I was recently discussing this sort of thing with some friends and got into what I would love to start as a project - something to the effect of "fvs" or function versioning system - which would allow me to keep tabs on "just-a-box" functions which i use throughout my programs.
I think any programmer who sees the benifts of CVS would understand where im going with this concept. We all have functions we use again and again - and realizing that there is a potential flaw in a given function at one point is always followed by exasperation because one realizes that the function needs to be changes in X number of programs.
No need to haul out references to books or count buzzwords...just look at the software world and the question answers itself.
Since the early days of computing in the late 70's, we've seen systems grow more larger and more complex. Whereas entire OSes used to be written by a single person (granted, a gifted person like the Woz or Bill Gates), these days we have companies like Sun and Microsoft with literally hundreds of developers and testers for a word processor, let alone the thousands of folks around the world who contribute to Linux, Apache, or KDE.
Given this incredible change in how software is developed, we'd expect to see systems collapse into instability and mayhem, but save for a few exceptions (Windows 9x, anyone?) this has largely not been the case. Windows XP, Mac OS X, and Linux 8.0 have proven, if anything, more stable and reliable than their predecessors. For an even more dramatic example, look at NASA's software or popular video games. It's clear that not only has software development expanded in scope exponentially, but it has become objectively better in the process. Development has never been better, and I see no reason why this trend shouldn't continue.
Karma: Good (despite my invention of the Karma: sig)
Let's say you're trying to improve the work of a painter. Give him a better brush, his strokes look nicer. Give him better paint, his colors look brighter. Give him a CAD system with a robotic painting arm, his paintings look crisper. However, nothing you've done can change the fact that he's still doing velvet Elvis's. Not that there is anything wrong with that, but he isn't churning out a Mona Lisa anytime soon, or ever. You haven't been able to affect the input to the process - his brain. You know the adage, garbage in, garbage out. Well that is the fundamental rule in software.
The big improvement in software productivity will come when we are able to successfully clone human beings. Corporations will create a stable of uber-programmers who they will then clone to be able to mass produce software. In the future, the open source war will be about peoples' genes, the software will be just a downstream product.
There are definite improvements to programming. Tools, concepts, etc. have evolved. There are no true silver bullets, but we've got a good selection of choices out there.
The problem, however, is threefold:
One of the real challenges for IT professionals today is to find the good tools and ideas out there, the ones that really have improved programming, and then actually get them into use. A good IT person is a good researcher and good at justifying their ideas to people.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
what "improvements" over the last quarter century have actually brought progress to the key issue: more quickly and more inexpensively developing software that's more reliable?"
I've only been programming for 19 years (not 25) but I can say that I've seen absolutely no progress in software development givin your contraints of defining "progress" as being able to achieve the three goals (speed, cost, robustness). HOWEVER, I don't really blame the tools, rather the nature of the end result. The software we have to write has become significantly more complex, and at a rate that has surpassed our abilities to effectively create tools to deal with their complexity. "Back in the day" when a "good" business level word processor was 100KLines of code and written by a small group of dedicated and bright people, you could get very good results. Now, something like Word is significantly larger than 1MLines of code being worked on by programmers with 15+ years of experience to those who just got out of school to those who you wouldn't trust to add up your grocery bill let alone write a line of code.
It's like we still have hammers and nails, but the "market" wants us to build steel skyscrappers. So we come up with even better hammers and whiz bang processes to "better" utilize those hammers and nail together steel girders, but the fact is that those tools are woefully inadequate to truely make a dent in improving that which we build.
Languages are definitely better. But there are also a greater number of software engineers, many of them mediocre. So overall I wouldn't say quality is better.
Think about it. 25 years ago, it was extremely limited. How many people did you know, in 1977 with a net account? I remember coding on a C64 in my cousin's basement for days on end just because we had scrounged enough money to get into town and buy some new books/magazines that helped us overcome some bug. Now, if you're being bitten by the same bug, whaddya do? Hit the net! Some of the responses above, like the sharing of source through GPL wouldn't be as viable an option without the access we have today. The biggest aid to programmers today. Net Access.
Don't park drunk, accidents cause people.
Bah. It's enjoyable - and college is all about getting a well-rounded education, right? So a CS degree doesn't mean you can't get a job - with any kind of degree, you've certainly got a larger selection of jobs you can get. Just don't plan on getting a job that has anything to do with computers. ;)
Have you read the Moderation Guidelines Addendum?
The law of leaky abstractions (Joel on Software) seems to address at least one aspect of why this software nirvana has not been achieved.
--Shashank
Software that impacts the way we live will never be written using eXtreme Programming.
EXtreme Programming will only work effectively on development teams of less than twenty or a dozen, whereas most large software apps require hundreds of man-years. To work effectively, these projects are (unfortunately) using Rational's suite of tools and approach to software design.
Pity.
In my opinion, object technology has done more to allow developers to re-use effort than any other paradigm in development. That isn't to say that the potential of OOP has even been approached. It is rare to find large development shops that have a consistent base of knowledgable OOP developers, and it isn't always necassary; it is very important to have OOP concepts influence the architecture of any system that maintains re-use as a design objective.
Design patterns also play an important role in allowing for a given design to be re-used, consumed, whatever the case may be. OOP related technologies such as UML, Corba, and now many XML based solutions are beginning to mature the field.
I am not as experienced as I would like to be with OOP, but I can say that I have been in the procedural world long enough to realize that there seems to be a divine power in OOP. It makes you *think* entirely different about problems, and by breaking a very large, very complex problem into approachable components. Allowing not only a single developer to build more complex systems, but systems that are well suited for re-use in future or existing systems.
Coors Light. Its done wonders for my hacking skills. No wonder its called the Silver Bullet.
Yeah, as a PhD student you get paid practically nothing (at least when compared to corporations), you have to work silly hours and possibly teach as well.
Yet, if you pick your topic carefully, you'll be working those hours on interesting and intellectually challenging bleeding edge stuff and not on some YAMC (yet another moron client) project that was handed over to you. In a nice group you can also choose whether you want to come in to work early in the morning or at around lunch time. Furthermore, teaching experience can never hurt a nerd. I used to hate teaching and I still don't like it. However, positive teaching experiences and the very act of confronting a group of smart, young people for four years improved my self-confidence, presentation and public speaking skills tremendously.
but in my world, Java is the single largest memory hog and memory-leaking piece of crap I have ever seen.
you're kidding yourself if you think Java keeps you from having memory leaks, and I have enterprise code to prove it
A year spent in artificial intelligence is enough to make one believe in God.
I can't say that Java is a significant programming advantage over C -- it's the Java libraries that beat the snot out of calling the raw Windows/Mac/X APIs.
That's not the only one: The depth of CPAN, the Python library, even MFC/ATL are worlds ahead of hand-coding the guts of an app.
When I started programming, the Mac SDK had to be handled raw, and GDI was brand spankin' new. APIs such as DEC's FMS were considered heaven-sent(talk about dead ends!). Shortly after, class libraries were available, but expensive for an amateur. With Java and Perl, it's part of the (free) package.
I'm sure there's garbage code in those libraries -- there's always going to be bugs. But they're going to be relatively smooth to use, and they're already written, letting me focus on the business logic, instead of the presentation.
Design for Use, not Construction!
If you're coding an app and you are spending time on the GUI you are just creating a maintenance headache for maintenance programmers later on.
Most documentation is horrid if it even exists (learn a human language first and use it to actually write meaningful comments, specifications, test scripts, internal and user documentation.)
Most of this industry doesn't know dick about SLAs or optimization for time (first) or space (last.)
Most of this industry doesn't know dick about configuration management, capacity planning or correctness.
The difference between duffers (most of this industry,) and the pros is that the pros don't "paint little master-pieces" in a a guild-like cottage industry. They generate "art by the yard" in industrial settings for mass dispersal, distribution and "invisible" use.
Good luck and remember, computing is nothing but a problem in N-Dimensional topology. If anybody tell you different, they are part of the problem, not part of the solution.
ALL objects have states and state transitions, code for that first and the rest will follow. Start from a thorough, correct and complete meta-model and you won't get into trouble later.
As for languages, CASE tools, GUIs, IDEs and the rest. Learn to do it the long and hard way first so you'll:
a) know what's being optimized and abstracted out,
b) appreciate it,
c) know what happens when it fails.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Many people resolve this issue with shared libraries.
What I have observed in the course of software development, in various companies, is that the management dictates that "thou shalt follow said process" and there will be the obligatory design reviews, spiffy diagrams, an all the huffing and puffing. But when the smoke clears, it still comes down to 9 months of work compressed into 3 months of actual work time, and everyone shifts into a hack 'n slash mode. The processes in place fail because of a lack or adequate time and inflexibility of deadlines.
Be excellent to each other. And... PARTY ON, DUDES!
* Please try to keep posts on topic.
* Try to reply to other people's comments instead of starting new threads.
* Read other people's messages before posting your own to avoid simply duplicating what has already been said.
* Use a clear subject that describes what your message is about.
* Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)
* If you want replies to your comments sent to you consider loging in or creating an account.
Having been at the software development game for about 20 years, I've been through the structured programming/data flow design/yourdon/OMT/UML methodologies at various levels of expertise, tools from vi/cc, borland turbo pascal/C on 8086, dec 10 and vax/vms fortran, visual C++, Jbuilder, etc. I haven't seen it all by any stretch, but I've seen enough to know that it hasn't all changed that much. In my time, we've just moved from designing libraries to looking for patterns, which has the side effect of resulting in somewhat useful code. Bottom line is the stupid little detail that was forgotten, or a missing key piece of info from the spec or customer causes endless havoc. If anything, the situation is worse because what we do has gotten more complex and the tools that we work with are essentially leaky abstractions (see Joel on Software) and if you didn't work at the low levels when your latest whizzy development environment doesn't produce code that works, you'll have a pretty difficult time figuring out the problem. Its still a black art, experience counts, and don't believe everything (anything?) the buzzword compliant managers or sales rep say.
The irony is that it may require technological stagnation (ie, no improvements in hardware, etc) before programming can become an art or a true engineering/science discipline.
Now I am not saying that you still don't need to have a good understanding of the language, or use good design, implementation, testing, etc. But I have worked at SEI CMM level 3, level 2, and am currently going through the process of evaluation where I work now, for level 2. But being at that level doesn't guarantee that your software will be good. It seems almost like we are attempting to fit the creation of software into the old engineering mold, because it kind of fits.
So to answer the question - I don't think that there have been any great improvements to obtain the goals you stated. Software relys on hardware, which seems to contstantly be changing. A bridge is a bridge, but the very idea of what software can do has been changing constantly over the last 25 years.
If you want reliability, look at what NASA has produced. Those are some engineers. Ahh, but you said 'quickly', didn't you? :-) If you want something rock solid, you can't have it tomorrow, if you want it to do anything remotely complex. I think one of the big things we as an industry has to realize is that our product (software) can be simple and fast to market, or more complex and take more time. And all of the variations in between. I haven't been convinced that what we do is engineering, but I haven't been convinced that it isn't. After all, it is a pretty young profession, compared to others. Imagine trying to explain to someone from 100 years ago what a software engineer does.
All that being said, I think that the obvious Slashdot answer is that the GPL and free software have been a huge force, but only in recent years. I think the two biggest forces in software development were the PC and the internet.
My beliefs do not require that you agree with them.
The human and the computer.
The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.
What sort of programming do you do? I've done machine tools programs and xml to Oracle data converters and I spend more time developing algorithms and data structures than I do wtriting code.
Best Slashdot Co
As a professional developer, I've seen complexity for even simple solutions skyrocket with a concomittant loss of performance with the current obsession on over-inheritence and Java-style interpreted/P-code software overall. Add to this GPL/OS that slashes meaningful business value from well engineered software components and I think we have retrograded from the vanilla unix with tough, straightforward C coding.
If it were done when 'tis done, then t'were well it were done quickly... MacBeth
There have certainly been improvements in software development, but they generally only address yesterday's problems. That is, as one improves the process, instead of making life easier, the complexity of the project simply increases.
My personal theory is that the complexit/hardness of software development is more or less constant. Putting together that "monsterous" 1000 line COBOL program yesterday was probably just about as hard as today's 100,000 line Java program.
After the 1000 line COBOL program, you have to do better, add more features and use a richer model. This entails increased complexity. While you may have gained valuable knowledge, skills, and new techniques in making your 1000 line COBOL program, now it's time to move on to the next level. The new stuff you developed helps you get to that next level, but you end up working just as hard, and the problem is just as difficult.
The next big step you can watch for is true AI, and as Jaron Lanier points out in his article ONE HALF OF A MANIFESTO, we're a long way from it.
New programming languages can be clever and sophisiticated - but the next step - regardless of the language, is programs that can write programs.
(mind you im quite sure these programs will use CVS!)
IMHO, one of the keys to writing good software is to not write very much software. Class libraries like the one in Java are almost invariably more feature-complete, more reliable, and better tested than roll-your-own libraries. Using existing libraries means you don't have to worry about off-by-one errors in your linked list implementation, or figuring out a good hash key for your string. While I think that all coders should know how to solve these problems, they shouldn't have to as part of their daily life. It's busywork, and giant class libraries do a wonderful job of making life easier. They let you concentrate on the important stuff - the algorithms, and marketing's feature of the week.
Yes, libraries have been around for more than a decade. The STL and Java both showed up in the mid 90's, though, and I'd argue they've made a huge difference since then. Yes, they have bugs. Yes, there have been other advances. Yes, there are special cases where standard libraries aren't appropriate. There's no silver bullet, but standard libraries are a huge advance.
That's what code libraries are for just rewrite the function in the library, recompile the library, and relink the other programs... or even better, put it in a dynamic library and just recompile the library...
software has gotten more complex and user expectations have grown at a rate equal or greater than software development tools.
Oh, Boo F'in Hoo for you and your friends.
I graduated back in the early 90's crunch and faced the same sort of job market. Good tech skills but no experience landed me a lot of (literal) envelope-stuffing jobs with which I barely paid rent and bought food for many, many moons.
Things changed. Diligent searching and studies found me an employer and then the late 90's boom happened.
Sure, there were a few lean years in the beginning but starting my career in a recession pounded one very strong lesson into my head right off the mark: The business cycle is real and Winter is _always_ going to return.
A few years from now, when the economy's going strong again and your salary is in the stratosphere, remember what it was like to scrounge change for a cup of coffee. Keep your skills current, keep yourself solvent and, for God's sake, don't get cocky!
There is always a demand for smart people who can get things done.
It's not that bad. Just stay in school (for your Masters or even PhD) until things are better.
Find some other career. Like be a male stripper or something else that has regular hours.
Is this thing on? Hello?
It definitely seems that programmer rely on the faster hardware to have the same performance with less efficient code.
All the problems with software today aren't a result of poor engineering, but rather of poor software development management.
;) But most business orientated software is bug-ridden, and that's just fine. It's the accepted risk for getting the software out the door as cheaply and quickly as possible.
I can't count the number of times last minute feature requests are required to be in a build. As software developers, we just deal with it. But quality suffers because of it. And the engineers get the bad wrap.
Do you think Intel management requires last minute features to the Pentium core, and tries to push them out the door with no testing? Do you think people building cars for Toyota decide to swap engines at the last minute, becuase GM just put a turbo charger on it's standard Prizm?
It's ludicrous the stuff that gets requested of software engineers.
My brother is an contract electrical engineer. He was complaining one time of a 'last minute feature request'. His project still had a year of development time left! I laughed so hard I almost puked.
Granted, given all that, the current model for software works. When software is required to be bug-free, it can be. Lots of software is bug free. You just don't hear about it, because it works. Look at NASA, the AIN telephone network, or Windows.
I don't have a sig...Do you??
from what I can tell programmers (or if you are self-important, Software Engineers) haven't improved at all, but management has. Languages like Java and stuff like UML and pure OO development aren't really aids to programming, they're aids to communicating your design to management. Management is thus more clueful and will allow the good shit to go and the slop to go back to the drawing board.
Software is like any sort of engineering, really. If you spend the time designing properly, prototyping what you don't know, and document everything carefully, you'll get the same result as people who do the same building a bridge or a tank.
This assumes however, that requirements don't change. The sad fact is, in software, requirements change a lot. Unless that changes, software will always take longer than people want/expect.
To give an equivalent engineering task, look at the Bradley Fighting Vehicle that the U.S. Army "designed" and built. Watch "The Pentagon Wars" with Kelsey Grammer. Great movie, BTW. The requirements for the Bradley were changed over and over again through its many, many, many, years of development. It's an armored car for God's sake. At least that's what it was supposed to be.
It took them something like 15 or 20 years to get to production to build what amounts to a tank that's as fragile as a Pinto. Fortunately it's been improved since then.
Anyway, if your requirements remain static, then doing software "quickly" using any of the many modern tools and processes available today is quite acheivable. Quickly being a relative term and all, but compared to the old days.
Do you see users who exercise self discipline and request for less features? No. Users always ask for more features than they remembered exist.
How many managers really tried hard to dissuade adding that nonsensical feature? Why should they? In the first place it would jeopardise their promotion and there'll be less chances to score points.
There are so many times in my job as a system analyst, i question the need for additional features or new applications. But it seems hardly anyone sit down nowadays to do a proper cost/benefit analysis. They just want to push more applications/features out faster and cheaper.
There in, i believe, lies the problem. With any technology, people eventually becomes greedy and tries to push it to the limit to satisfy every possible fancies that they have while ignoring its costs. As long as we keep misusing and abusing any technology, sooner or later, the law of diminishing return will set in. IT has its limits too.
Reality is what we taste, smell, see, hear and touch yet we cannot comprehend it...only approximate it.
While people seem to be saying there haven't been any advances, and won't be any advances, and such, they're forgetting that the first key step in solving any problem is identifying the problem.
People are complaining about how using stronger employees to lead less-skilled employees doesn't work. People are complaining that the person testing the "bad coder's" code is usually the "bad coder" itself. These complaints begin to define the actual problem of "Why software development isn't improving." Each of these complaints, taken together and addressed, is the first step towards improving software design methodologies.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Whoa! Talk about arrogant and complacent!
Systems engineers from India (etc.) are becoming just as good, and much cheaper.
Your turn will come.
Here is my take on the best environments available today (in order of best first) - I only include stuff that I use:
- Cincom VisualWorks Smalltalk - a really fast coding environment with support for SOAP/WSDL/UDDI/all possible database connectivity, built in web development tools, huge class library so often new applications are very little new code
- Microsoft VisualStudio.Net - I almost hate to include this one, but I am trying to be honest here
:-). Last year when I was writing a J2EE (Java Enterprise) book, I took a good look at the competition and liked C# and .Net.
- Java with light weight web services - I am a HUGE fan of Java on the server side, done light. By light I mean that I like to just use servlets and JSPs, etc. and only use heavy weight J2EE stuff when I really need transaction support, etc. that EJBs provide
- Common Lisp - lots of great commercial tools from Xanalys and Franz, and lots of great free tools like CLisp, CMULisp, OpenMCL, etc.
- Python - Love it for small projects, munging text, etc.
- C++ - only use it when I must - great runtime perfromance, but a pain to code in
It seems like so much work today requires deploying web services so I appreciate tools that make it easy to develop basic application logic separately from any user interface, get it working, then write web and/or standalone GUI interfaces.-Mark
Warnng: I am blogging now: http://radio.weblogs.com/0115954/
I think the English word you are abusing is 'your'. You're is a contraction of 'you are', which doesn't jive with the context you used it in.
Good rant though.
Glonoinha the MebiByte Slayer
I think the varying degree of control over the physical machine a developer can now choose when writing a program is the single most important factor in increased productivity. In assembler the programmer must worry about everything. C was the first truly abstract programming language where the programmer could call a routine like printf and not need to worry about the details of printing a string to the screen. Because the language was more abstract, the programmer could do far more complicated things (have you every tried to write a red/black tree in assembler)?
Over the last several years languages have gotten more and more abstract, languages like Java isolated the developer from pretty much everything except the logic they are trying to capture. Developers can now choose the level of abstraction they wish to work with based on the problem domain. (low level library vs. script for renaming files) Higher level (more abstract) programs are usually much easier to write but it is worth noting that there is a price to pay for, generally these programs are not as powerful as their low level cousins. Some languages like VB still try to abstract development out even more, so that it is accessible to everyone. Abstraction has brought the ability to program to a much wider audience and has greatly reduced the time it takes to write basic applications and for that it is the most important change in programming.
One large thing that prevents improvement is confusion between what's changing and what's not.
Each year we have large increases in hardware performance and new types of hardware. We also are also playing around with the best way to "talk" to computers with new computer languages and such.
On the other hand, there are things that are basically the same year after year. How to do quality assurance. How to gather requirements from customers (users). Some of these things are basically no different than things delt with during the industrial revolution...
I'm very wary of assesing the value of some "new" paradim until it has been around for 10-20 years. Every 5-10 years we have something new fad that is "going to change software engineering". We need to concentrate on the things that *are* changing and the things that are staying the same. Just because my CPU speed is going to double in 18 months isn't going to fix the fact that I'm not properly testing my software properly. Or that it doesn't do what my customers want.
I believe that, in general, code is now better than ever before (through a variety of software tools and development processes). The problem is that the number of lines of code in a typical application has now also increased so that there about as many bugs per application as there were before.
Sig (appended to the end of comments you post, 120 chars)
And live on what? Air?
This would be overkill in the situations im talking about. I believe a simpler example would better illistrate what i meant.
I have a perl routine which i use in many many scripts i've written, its called file_to_array, and im fairly certain you can ascertain its function.
I'm not going to be using libs for something like this. This is just one *example* of where i could see the usefulness of a program like fvs - for those small programs which use specific user defined functions.
overall the benifit of something like 'fvc' would be truly harnessed by programmers that find them selves always writing little programs and scripts for which they tend to resuse stuff they've already written.
Being that CVS is OSS, perhaps someday i'll get the time to use it to write such a program.
Development methologies may have improved, and frankly, i believe that. however, most software is not just developed with the latest and best practices alone.
What really drives development, from my experience, is that grit that resides between the client (or target) and the developers: the management. And my experience more than not is that they:
1. don't care about best practices and just want it done
2. Care, but don't have budget or schedule - or so they say.
Bottom line is that everyone (or at least all managers) want it on time and under budget. But rarely can you get the two. This translates into cutting corners which produces shotty products which, in turn, makes the developers the scapegoat.
I was thinking the other day "what if more software was developed more the open source way - things usually don't get released until they're ready and where code is more peer-reviewed?" How would this affect the software industry? What would the upgrade cycle look like? What would the security landscape look like? Would there be a software industry today as we know it? Who knows?
You can release good products on time. But there has to be a orchestrated effort between management and development on what can and cannot be released in a reasonable schedule. Unfortunately, most of the shops I've worked with tend to ignore that and thusly, it doesn't matter what process or tools you're using since the integrity of the product is damaged from the onset in such a severe way that what ends up happening through the rest of the product lifetime is a catchup and patchup feedback loop.
This will sound "stone age", but:
- The web browser as an easy and widely available client interface.
- Basic HTML and CSS created by CGI Perl
- The universe of Perl modules
You can build lots of fast, interesting stuff with that toolkit. Plus it is fairly easy to use (fast "make a change, refresh, make a change, refresh" cycle).
And when you want something graphical, add an applet to the mix.
There's a big piece of self-deception that's been with us in various forms for, um, five decades.
An early phrasing of this deceptive might be: "Every FORTRAN statement generates ten machine instructions, so you will be ten times as productive writing in FORTRAN than writing in assembly language."
The problem is that when you're doing it right, programming progress is exponential, not linear. Every time you do something as simple as calling a subroutine, you're writing one line of code that is the equivalent of ten (a hundred, whatever). If you're doing it right, you write subroutines, then subroutines that call subroutines, always leveraging what you've done before.
So something that seemingly gives you a multiplier (in terms of instructions executed at run time per unit of programmer work time) is really only additive (in terms of project progress).
For example, what's the effect on productivity of being able to call strcat? Let's suppose the implementation of strncat is twenty lines of code. Every time you use it, strncat does NOT give you a twenty-fold multiplier. All it does is save you the time it would have taken to write strncat ONCE yourself. (And test it, and document it--but still, only ONCE).
Most "advances"--a good subroutine library, a good language, object-oriented programming, rapid application development tools (yes, Visual Basic--go ahead, flame me)--have the same effect, when they work. What they do is to start you further along in the development process.
But it's just a head start, it's not an increase in development speed.
And, of course, all of this is counterbalanced by the time it takes to learn the tools. (Is strncpy guaranteed to give you a terminating zero byte? How about strncat? How sure are you?)
"How to Do Nothing," kids activities, back in print!
I think any programmer who sees the benifts of CVS would understand where im going with this concept. We all have functions we use again and again - and realizing that there is a potential flaw in a given function at one point is always followed by exasperation because one realizes that the function needs to be changes in X number of programs.
You don't need a new version control tool, you need a refactoring tool.
...but little progress. I'd say that the one area programming has made leaps of progress is in functionality. But if reusability is the measure of progress, and it is a requisite, then little progress has been made since McIlroy formally introduced the world to highly reusable software components.
.sig
If I may actually provide an opinion rather than just rant (I know, it's dangerous here at rant.slashdot.org)...
Design By Contract is an excellent step towards highly reusable components. In order for a component (in its loosest definition) to be reusable it must also be correct. But correct is relative. The requirements, or the contract, must be apparent to the user (client). The run-time should check the requirements for you, and this run-time checking should have the ability to be turned off. Furthermore, in the object-oriented case, the contract should be inherited providing a framework for more specified descendants. DbC is a good tool for providing these.
This is a
Sounds like you had some problems getting out of bed. Extreme Programming is good in the right environment and remember the best rule of XP, "They are only rules." You need to take the best out of what you find and make it fit to your situation.
And me without Mod points. Well stated.
Holy s-, it's Jesus!
Small-scale development has always been efficient. The challenge facing the industry has been to find ways of doing large-scale development (the type Fred Brooks was talking about) cheaply and effectively.
And in this domain, there has been a revolution, namely the Internet, and the arrival of cheap connectivity between developers anywhere in the world.
Prior to this, the only way for developers to collaborate was to be hired by the same company, work on the same network. Inefficient as hell.
Today any group anywhere in the world can create a project and work on this as efficiently as a small group in the past.
The irony is that the revolution does not care a shit about the technology used, and works as well for COBOL programmers as for companies cracking the human genome. It's about solving a purely human problem: communications.
Sig for sale or rent. One previous user. Inquire within.
>There is always a demand for smart people who can get things done.
True. But more and more of these smart people are in places like India and former Eastern-bloc countries where as well as being smart, they are very cheap!
I predict that very few people in the US and Europe will be employed to develop software in 5-10 years time.
Unfortunately, the tools for helping us to specify what we want/need are woefully inadequate. Hence, software development is both art and science. If I see any clear trend over the last fifteen years, it's that we're getting worse at *thinking* about what we want and "better" at creating vast amounts of code. Oh we're better at diagramming, syntax-error catching, etc., but the ideas are what's important, and there are no tools that can help us think through what we need. There is no substitute for intelligence.
In the 2nd Edition of "The Mythical Man Month",
Frederick Brooks lays out a summay of various rebuttals to "No Silver Bullet" (there have been, 'a couple' of papers on the subject)...
Its worth a read.
No, there haven't been any improvements in the last 25 years. Only "added features".
I still work using IBM Smalltalk. I had a good laugh when I read the linked Smalltalk thread and some of the comments. "Smalltalk is too slow" followed by an example from "Squeak" complaining about how some noob's Postscript implementation kept copying huge object trees thereby eating up all the machine's memory therefore damning the whole language as "ineffecient" (compared to your-favourite-language). Many of the features in Squeak are HORRIBLY IMPLEMENTED! It has lots of features but there is no consistency in the code. Please don't use some lame Postscript goody as a basis for language performance.
Anyway, this is a perfect example of why there are no "silver bullets". People write crap code. It's not the tools, it's the people.
Yeah I have. It is impossible to use and difficult to find any documentation on. It is a joke of a development suite.
Anything that is an abstraction (which is what all of these tools and methods rely on) leaves something to be desired. In fact these tools/methods usually make something impossible, or totally arcane (read unmaintainable), to implement.
So as many have said: you have to pick and choose.
However: learn C (or C++ without too much reliance on the OO parts of it) and use it in a major project.
Why? Because everything else is just window dressing piled on top of it. If you truly want ot be a CS (and not just a company development slave) then you have to learn as "close-to-the-bone" as possible in order to later learn what all of the other stuff is really doing, and not doing, for you.
Only once we get into "programming" for quantum computing is there really going to be CS-level progress. All this other stuff was originally just ways to get commercial support for CS departments and projects. Commercialization of CS theories are a big business in which new initiatives echo around for many years until they die out.
An example: "Fourth Generation Languages".
The only survivor in the big scheme is SQL.
That is a "big" survivor but all of the other variants have faded or have been hidden within some of the newer next-best-things.
Yes there are incremental improvements but logic is logic and storage is storage. Everything else just allows us to not think about trivial things when we are sure they are trivial. However, since when is any detail, especially an omission or unconcious commission, truely trivial?
Software (design and) development is all about passion. Only mechanisms to express the road to success have changed (and improved). Experts look for species like good software developers, analyse them and define a new process. And most of them are not wrong.
There are hardcore believers of waterfall model. And so goes with extreme programming. Configuration management is luxary (and waste of time, sometimes) for somebody, and may not be same for others. The best part is, we have methods suitable for individual's nature.
Hmmm... Ok.. Chivas on the rocks.
And believe me, as small as the pay is in comparison with the corporate wage, it sure as hell beats the pay you get flipping burgers, stuffing envelopes or living on welfare. You also get to choose the time you want to come to work and plenty of free bandwidth.
First of all, glad to see a lot of positive posts on this topic...I frequently see on this very same site laments about the dismal state of software. I am in agreement with the viewpoint that software developers continue to be more and more productive (through frameworks, code reuse, improved languages and tools, etc.), however the productivity hasn't resulted in improved software quality because we are simply being asked to do more complex tasks with the same schedule and resources.
One thing that has drastically improved my productivity is the Web itself (time on Slashdot notwithstanding), as a way to locate resources for programming. Almost any algorithm, component, or subsystem that is not specific to the problem domain can probably be found on the web, whether as a library, a set of source code, or simply a precise definition of an algorithm. I agree with one post that a lot of young developers would have difficulty writing a correct bubble sort, but anyone that attempts to design and implement a bubble sort on the job is wasting resources, since there is an implementation somewhere on the Web in any language you would want. In addition to software projects, informative articles and API documentation, newsgroup discussions are invaluable as well for pinpointing problems. So the Web is really my most important programming tool.
In conjunction with the Web, the vast supply of open source and free software out there that has drastically improved my productivity. The Apache Jakarta project and CPAN are my favorites, but there are many interesting projects on SourceForge and FreshMeat as well. Often, even if you are determined (or required by corporate standards) to roll your own, free software can give you a good idea about how others have approached the problem and the abstractions and metaphors they've used. In my experience, design reuse is often far more helpful and practical than actual reuse of code.
Software development, at least many types of software development, has changed, in that programmers are much more dependent on large APIs and libraries than they used to be. In theory this is good, because it saves work. In reality, it has turned many types of programming into scavenger hunts for information. Now you have to hang huge posters on your wall showing object heirarchies (you didn't remember that a Button is a subclass of BaseButton which is a sublcass of ButtonControl which is a subclass of WindowControl?). Now you need online forums so you can get a consensus about how a certain API call is supposed to behave in certain circumstances. Quite often I feel I could write a new function faster than locating information about how an existing function is supposed to work.
it made me good coder. i drop text box and button on form. i double click button. i get code window. text1.text="hello world!". make good money too. friends think i'm 37337.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
Brooks, in the "No Silver Bullet" essay referenced above, stated that there is both essential and accidential complexity in software development, and because of that there never would be a "silver bullet" to slay the software "monster". However, there are fundamental practices that increase the likelihood of success and fundamental pitfalls that every project faces. And, in the end, the root causes of most failed IT projects are human factors; in fact, you could just cite the "seven deadly sins"--pride, envy, gluttony, lust, anger, greed, sloth--and probably hit the nail on the head.
In conjuction with that, far, far too many practitioners in the IT field lack one or more of the following:
To quote George Santayana (who is often misquoted):
Software engineering is hard enough--with all the human issues--without further handicapping ourselves with ignorance of all that has been already discovered and documented. Yet that is exactly what most IT workers do. Until we find a way to solve _that_ problem, the failure rate for IT projects will remain high indeed. ..bruce..
Bruce F. Webster (brucefwebster.com)
I think the ingredients you mention have made production of software a better process over the past 25 years. Software applications can do more and can be built more quickly as result of those improved tools available to developers.
However, you still see a great deal of unreliability, bloated, and inefficient code because developers are trying to do much more than they did 25 years ago.
If all we needed to do was re-create the applications of 25 years ago, then the benefits of new techniques would be more evident. But people demand more and programmers want to create works up to their full personal potential and exceed what is currently possible.
Ragged-edge software is manifest evidence that we still are constantly crossing the barrier of human potential, that place where what is barely possible becomes what doesn't work. It's a good sign of innovation. And, it provides added impetus to keep trying to find more ways of improving the software development process.
"Provided by the management for your protection."
Scary how this rule keeps coming back time and time again.
No problem is ever going to be like any other problem, expect in the abstract. 80% of what you will need to do for any family of problems can be turned into a module / code base, but beyond that you will have to start customizing your code to the partitulars(sp?) of the problem.
And let's face it, 80% of your time on the project will be working on the 20% customization.
III.IIVIVIXIIVIVIIIVVIIIIXVIIIXIIIIIIIIVIIIIVVIII
As any follower of the Tao knows. The software has always been there - the coder simply allows the Code to BECOME the software. Only new coders try to create the Code - followers of the Tao let the Code shape itself.
;-)
This is the way it has always been - and will be forever.
-- These views are my own and do not represent those of my employer in any way.
It is obvious that Microsoft has been the fantastic driving force behind software innovation over the past two decades. Their uncanny ability to feel out new markets and met the needs of their customers with cost effective, friendly licensed, quality software has forced all other developers to increase the quality of their products.
Software development will never be made reliable and inexpensive until we get rid of the programmers.
Software development is a cottage industry and "art" where artisans produce one of a kind products. No two programmers will produce a program in exactly the same way.
What we need is an easy way to translate analysis directly into code in a reliable way without human intervention.
This will give us the consistency and repeatability that translates into reliability and lower cost.
From the article:
The most a high-level language can do is to furnish all the constructs that the programmer imagines in the abstract program.
A-men. But if it does that well, then it makes the job a lot easier. That's why going from C to Java or Perl was sheer relief. Actual strings? Real associative arrays? Whoohoo! And less memory management grief. Not to mention the component libraries available for things I hadn't even thought of yet. CPAN...
To be sure, the level of our thinking about data structures, data types, and operations is steadily rising, but at an ever decreasing rate. And language development approaches closer and closer to the sophistication of users.
True... but the user sophistication is increasing to. It seems highly apparent to me that with more experience and more shoulders to stand on, language and component developers are able to concieve of more and more useful abstractions. And because of the internet, they're more easily available for sharing, commentary, and change.
To sum up, I am much, much happier with the readily available toolsets I have access to now than the ones I had 15 years ago, or even eight years ago. They make developing much easier and much more fun.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
Title says it all...
>Has Software Development Improved?
No. As soon as a developer gets a clue, they get so discouraged by the madness of the industry that they change careers.
Being a truely good developer requires a shift to the right side of the brain, at which point the infinitely interesting ways one can use the right side of the brain become apparent. And software development turns into "just a phase" we pass through.
He needs someone to solve serious problems his brand new Homeland Security Office has. There are, for instance, "...technical issues such as how to handle incompatible e-mail systems".
> earnest_deyoung asks: "Twenty-five years
... :-)
> ago Frederick Brooks laid out a vision of
> the future of software engineering in "No Silver
> Bullet."
But the article was written in 1987
Actually I think programming has gotten *MUCH* worse with GUI based programming environments like Delphi, VB and even Visual Studio. These tools strongly encourage painting the program and responding to events rather then concentrating on abstractions, infrastructure and good design. In making things easier, they fail to allow programmers to understand what goes on under the hood and most younger programmers (who never really had to understand what goes on) are programming via wizards that assumes a certain architectures and approach. Outside in (GUI based) programming methodologies usually collapse after programs reach a certain size and complexity.
Although being a fan of software development process
models, UML and even formal methods, here I am,
hacking away
-- without a specification (spec-on-the-fly)
-- with a broken and buggy win32 api-s below me
-- with undocumented legacy code above and beside me
-- with no real deadlines (moving-target)
-- no code reviews
-- no real test cases (too complicated)
-- no time to educate the bosses and change the company way
Sad Ha?
All of the above. Each has brought improvements to some aspect to the development process in certain projects. Next question?
--
CPAN rules. - Guido van Rossum
Well, so far design tools are primarily based around UML, which is useful and helpful, but certainly hasn't been the answer to the prayers of software engineers. eXtreme Progamming is more of a process model and not a design model.
.h's and .cpp's. I have no idea why as I type a function declaration in a header (assuming it's not virtual) it isn't being added to a .cpp. Developers spend hours a day dealing with processes that could be greatly improved. Interfaces for handling complex code could be done. Don't get me wrong, there are some companies/people trying to do this, but it's really hard. It's what we should be trying to figure out.
I would say that visual languages have done a great deal for prototyping, the unfortunate fact being that those prototypes are seen an used, and development of a true solution forgotten. (The only reason i can come up with for the proliferation of VB applications)
Off-the-shelf components have not taken off, though the game development community seems to be one environement where this can occur quite succesfully. The key being cross-platform. So many "off-the-shelf" components are sold only as ActiveX controls. What does that get us? Those developers taking the time to write a robust physics engine are writing it in C/C++/etc and marketing to people who can use it on any major platform.
What have we gained as far as real usable helpful tools? Not much. We still type out our
We need to integrate our design tools with our solution creation tools. This goes above and beyond code generation, refactoring needs to be a major component.
Good designers can make do with just about anything, but we need to enable ourselves to do better. Unfortunately it costs money, and companies don't like to spend money on code tools.
Cheers.
- Sighuh?
Libraries are the silver bullet, always have been, always will.
It doesn't matter as much what kind of language you do, declarative or imperative - functional, logical, object oriented or procedural. If you haven't got the libraries, you're not going to be very productive.
To build libraries that can stand the test of time requires inhuman efforts in design, simplicity, flexibility and elegancy. Any system that lack this herculean effort, will remain inferior in terms of software development efficiency. Also, the implementation of said libraries will form, shape and both enhance and limit the ability of the developer. It is also very important that the libraries can stay current, and not "grow old with age", without breaking too much (yeah right!).
So while many types of languages touts enormous advantages, the developers on said platform are not going to benefit unless they develop a community of collaboration AND a standardizing body.
Then there is the argument of "the right tool for the right job". Functional is NOT "better" than procedural in this context. It may be harder to grasp, but so is brainfuck, saying little of what is "best".
Eg: Currently, the language with the cleanest human readable syntax, is Ruby. Although limited compared to functional languages, this beautiful gem of an imperative language should stand out as an example in simplicity the rest should follow (just as we have many C-like languages now, Ruby-like languages should follow).
But Ruby falls apart in the library department. It would be best to scratch all the custom-hacks they call libraries and start all over again. This is the hard and naked truth. These libraries doesn't do a power-packed language like Ruby justice at all! There is currently not even one descent hook-library, leaving overloading of procedures to faith and prayers nobody else will break yours.
Hopefully, the limitations discovered by the meta-ruby project will spur a movement into a powerful and even simpler meta-language, with libraries that can match the strength. Certainly, the ugly hacks in the language needs to be removed and replaced with standardized methods of handling "meta-stuff".
But building those libraries are STILL going to be the biggest task and the most important job...
Realistically speaking, it is still very early in the computer age. We haven't even begun to sort out some of the basic issues about what is really important to society just yet. Sure, we have great business tools, and we have cheap PC's, and we have diversity (Mac, Linux, Windows, Big Iron, embedded, ...), but the industry is so very young. It's still dealing with how to sort out what distribution methods work the best (free v not free?), what development paradigms work the best, and what situations or business models deserve what type of development.
This is where I think future Sci-Fi gets it right. You never see anyone there fighting to understand the newest user interface, or wondering when the bridge computer is gonna crash and reboot. No one ever talks about a 5 computer redundancy in the flight controls. Those are the ideas that all of the current work is moving towards. All of the books, all of the failures, all of the fighting, and all of the fast paced development will move us towards a happy equilibrium at some point.
Where is software development now? It's growing up. Slowly, but this isn't easy. It may never be, but sooner or later, it will be done in some correct way. That's the day you don't see a Mac switch add talking about how easy it is to use a Mac vs. a PC in my opinion. Or you don't read about how the newest US fighter jet may reboot a flight control computer in flight. And your mobile phone rings every time you expect it to ring. It's all about evolution here.
Bah
We don't know enough to do software engineering yet. If materials in the physical world were as poorly understood, and changed as fast as they do in the software world they couldn't do it there either.
If requirements were as poorly understood and changed as fast in the physical world as they do in the software world construction would cost a fortune and most big buildings would never get finished (or would never be fit for purpose).
People who say things like "Make sure the requirements don't change" are living in a fantasy world where they want to blame their inability to deliver on someone else.
The rules haven't changed, get a high quality small team, get good access to a user who knows what they want and grow a system from small beginnings, checking at each stage that it all works and that quality is high.
Its all there in Brooks.
Its no surprise that the guys pushing the agile methodologies were all very succesful designers and developers anyway.
Software development should get more and more productive as developers take advantage of class libraries, frameworks, and third party components, unfortunately due to political decisions in various companies things aren't improving as fast as they should be (at least in the Windows world). I see a lot of companies stopping development of the GUI side of things, because they have become "unfashionable". For instance, Stingray no longer make newer versions of their Objective grid product, even though there is a lot of new features that could be added to it. Also, in the latest version of Visual studio, Microsoft has decided to discontinue the MFC framework (I mean no new features will be added, it's still supported as regards bugs). In fact the MFC framework has seen scarce improvements improved since VC 4.2 (at least regarding GUI stuff, like components and doc/view architecture). Even where Microsoft add new components , they often are awkward distribution restrictions like dependency on IE.
Unfortunately we're stuck in a paradigm which doesn't leave much more room for innovation. C and straight-ahead procedural programming are still used for most complex systems, and C++/Java are used for larger systems where OO is suitable. Unfortunately for the advocates of each of the other popular languages today, a real change in thought is going to have to happen to bring them into the mainstream.
The largest hindrance to software design is the free software world, where far too many people are hacking code without the proper skills. Linux is already behind the eight-ball because of this - a million people hacking constantly without cohesive structure makes for chaos, versionitis, and distributionitis. These hacker kids don't have to interact with anyone they don't want to - in the event of a design disagreement, the kiddo takes his ball and goes home to start his own distribution. That doesn't lead to advanced design (or soft-skills either). Think of the 16 year old kid who has an inflated opinion of his skills - he's never going to learn a thing in university because the "hello world" lesson in day 1 will prove his opinion that this is beneath him. Unfortunately he won't be listening when the curriculum passes him by and leaves him in the dust in second year.
To the 16 year old wearing the "code poet" (shudder) T-shirt because you made the kernel print your name while booting: learn humility - without it you won't be able to access the most powerful tool of all: the wisdom of your peers. While that Knuth box-set looks l33+ on your shelf, you'd be surprised at what you'll learn by opening it.
I notice the original post mentions several things that could influence the development time of a software project. I will address a few of these below:
1) Object Oriented Programming :)
This is one of the bigger Silver Bullets to be unleased upon the programming world. I don't think it entirely lived up to the hype. Most OOP is just for local project design, and heaven help you if you have to reuse code somewhere else. It isn't just a case of bad design. Problems like software design are actually ambiguous. The design process is not algorithmic; rather, it's heuristic. You use "templates" and "patterns" to represent your ideas. Trying to shoehorn real-world complexities into these cookie-cutter styles is difficult at best. Trying to further take those styles and integrate them with each other in a very large scale product is a hair-tearing nightmare. I think Tablizer would agree with me on this...
2) Reusable components ;)
The most visible place reusable components come into play is GUI programming. It's very, VERY simple to use a visual-based system (like Visual Basic, C++ Builder, Delphi, etc.) to create a GUI simply by dragging the desired components onto the blank form window. If anything has been sped up significantly in the past several years, it has been the GUI development.
Components are, of course, used in a variety of other places, particularly in run-time libraries of various programming languages. However, learning to use these components effectively takes more time and dedication than one might suspect as the syntax tends to be rather cryptic looking.
3) Java
Don't get me started. I am currently employed as a Java developer. I don't really like it a lot. The file scoping rules bug me. (Similarly, I don't like Python because of the way it enforces indentation.) Also, the Java IDE sucks. Whoever thought the entire GUI needed to actually be written in Java needs to be taken out and beaten with a stick. A large stick.
4) The Internet (and OSS) ;)
One thing I noticed that you hadn't mentioned is the Internet. I have never been exposed to so many programming concepts and new languages. There is an astounding variety of tools, and thanks to Open Source and researchers at various universities, you can try your hand at as many of them as you have disk space for. The 'Net can be a wonderful place, after all.
My advice to any new programmer would be to get online and start reading. Download and try out new languages, especially ones in different paradigms, like functional programming. The tools you need (such as compilers, editors, databases, GUI component libraries, etc.) are ALL there, free for the taking. The only real "silver bullet" is to make yourself the best programmer you can be.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
One thing I always keep in mind when developing a project is something from my Electronics class so long ago:
The most important thing in developing a product is having the "right" design.
What he was getting at is that, if you rush into devleopment (coding in this case) without having fully thought the design though, you could end up shooting yourself in the foot later on. Redesigning and recoding something later on in its development cycle can be hideously expensive and time-consuming. Also, depending on the industry, it can be fatal (think lost contracts from being late). It's absolutely vital to think all the issues through regarding your product, not just in the short term, but what you might anticipate for the long (and in many cases, the very long) term.
Good, Fast, and Cheap can happen, even in software. If the aircraft industry can pull it off, so can the software industry. Read up on the Lockheed Skunk Works. They did incredible stuff with very few engineers in a very short amount of time. The key is people. You need a top-notch staff and more often than not a world-class leader. Such a team is hard to come by, but when they do get together they can pull off some amazing stuff.
It's pure OO, just like smalltalk, not hybrid.
It's syntax is easy to learn, write and read.
It has assertions nicely integrated into the language, everything must meet the precontitions and postcondition you set up. It feels natural to add checks and tests pretty much everywhere instead of cluttering the code with assert()s and #ifdef DEBUG..
SmartEiffel (the GNU Eiffel compiler) compiles to ANSI-C or JVM so it's portable to every platform there is.. Some other compilers can also compile to .NET..
You can use existing C and C++ shared libraries without wrappers/bindings. (although making bindings are preferrable to make it follow standard Eiffel-style)
It manages memory for you and has a garbage collector. You never have to think about buffer overflows and malloc()/free() again!
Its runtime speed is as fast as C/C++, and sometimes even faster because the compiler compiles to C-code that is more optimized than most human beings can code..
;-)
I could rant about it forever, but I won't.. Instead you should read one of these great tutorials!
Eiffel for beginners
Eiffel: An advanced introduction
Eiffel Object-Oriented Programming
And of course, the GNU Eiffel compiler: SmartEiffel
My other account has a 3-digit UID.
I wrote my first program using punch cards in 1973, and I've seen a lot of changes.
The two most significant are structured programming and the widespread use of interpreted (as opposed to compiled) languages.
When I ask an old-timer like myself to compare the introduction of objected oriented programming to structured programming, he usually agrees that, while OOP can be useful in many cases, structured programming is always useful and was a huge step forward.
Using a computer monitor beats the hell out of using punch cards, too.
To be honest, to throw my 2 cents in, we are seeing more and more bad programming. 20 years ago, you might have expected a program to have bugs. But know we see some of the biggest software houses and programmers releasing half standard programs, just to get them released on time. With many bugs still with them. And for the most part these bugs are bareable only because, our massive increases in hardware does not notice the odd memory leak here for a long time. To be honest, how many things we have designed over the years, would run on a 286, with 4 meg of ram. Fair enough you can't ask it to hand some of the graphics side, but the bare bones should at least run, even if you would be waiting hours for it to say Yippie. All in all, we can get payed silly money for stuff we write, and the pressure of deadlines makes some awful things. But on the plus side, those that do side projects, do end up being the best things around. As you dont want to release a personal project unless its perfect.
--+> Life, is there any?
Dr. Doug Schmidt hosts the Adaptive Communications Environment (ACE), which is essentially a C++ library or framework of building blocks. Although the learning curve is a bit steep, I have since created several Win32 NT-service client/server apps using the ACE library. I find that the ACE mindset simplifies design, and once the project's designed, implementation is very rapid since it's just a matter of gluing together various pieces of the ACE library. Please forgive my sorry introduction to this wonderful toolkit, and go read about ACE for yourself! You will be glad that you did!
This is where so many people get it wrong. Making software is not analogous to making buildings. Making software is analogous to designing buildings. (You'll notice that the Design Patterns movement is based on a technique for architects, not builders.)
(And, by the way, if you think real-world construction projects follow a simple waterfall model like that, you should read about the Panama Canal.)
What makes you think that if you design the hell out of it up front and build strictly to that design you won't find, six months or a year later when the project's finally finished, that you'll have built it wrong anyway? Or worse, what happens when halfway through you realize that your design was wrong, or your requirements were inaccurate or inadequate -- and you're locked into a process that requires a ream of up-front paperwork before you can change what you're building?
Again, coding is a design task. Everything else is just requirements gathering.
I think you've missed the point of XP's approach to unit testing. The unit tests aren't written to "check the code" -- I agree, it's pretty pointless for someone to write a test that proves that his code does exactly what he coded it to do. The unit tests are written to describe what the code is supposed to do -- they're like a design document that can automatically validate the code that implements the design.
Also, pair programming -- even when it's not between "two people of equal ability", so long as they both have enough ability and they're communicating well -- goes a long way toward alleviating the problem of having the watchmen watch themselves.
Don't knock XP if you haven't tried it.
-- Some things are to be believed, though not susceptible to rational proof.
Seamless integration with CVS, automatic refactoring tools, incremental compilation, full integration of unit testing, plug-ins, etc, etc... you owe it to yourself to try this fantastic open-source tool. /t
> I'm in a Computer Science degree program, and I > keep wondering what "improvements" over the last > quarter century have actually brought progress to > the key issue: more quickly and more > inexpensively developing software that's more > reliable?" Sounds to me like someone got an assigment entitled "Discuss improvements to Software Engineering in the last 25 years" handed out at the end of their last lecture.
One study I recall reading about (take it with a grain of salt) has shown that the average error rate in a program is 60 errors in 1000 lines of code. Some companies have managed to get that down to around 1 error per 1000 lines of code. Organizations that successfully incorporate the ISO 9000 model (Dilbert jokes barred) tend to have a much better rate. For example, code for a space shuttle only has 1 error per 420,000 lines of code - an astronomical (excuse the pun) figure as far as software engineering statistics go. Critical software development teams at Lockheed-Martin, for example, may spend up to two-tirds of their time in meetings and in design, rather than in actual coding. And the engineers tend to go home at 5:00 too. Just some food for thought.
An unjust law is no law at all. - St. Augustine
Well this is not exactly about languages and libraries but more about experience and use.
Frankly the market looks big but it looks bad. Yes, there were tons of improvements for the last 30 years. I still remember as a kid how my father had to fight small bugs in code by looking at the holes in the punch cards. I remember how terrible it was to fight Xenix in a S/36 and learn my very few first steps in *NIX. I remember the horror I got when I saw one of the very first PCs in Europe. It was a terrible world where the only help was the guru and yourself.
When I met the new OSes, Object Oriented Programming, RAD and all that pretty stuff out there I thought we had the road ahead and, soon, the horrors of the past would be gone. However, looking behind I see that we have lost something valuable - creativity. Today we use nearly the same things that were created in the beginning of the 90's. With the exception of Java, we have not seen any major revolutions in computing. Linux is not a revolution per se, in fact it is the congregation of revolutionary steps that were breeding for the last 30 years before its creation. Apart of this, Linux is quite old and conservative.
When you look at old generations, you see that 90% of what they did is what you do today. The only difference is that you either reuse their work or invent the wheel again. Most of the market got reduced to a bunch of architectures and programming technologies. We no longer see computing rooms looking like zoos, with every kind of hardware and software. We don't see people fighting for every bit inside the memory and making marvels out of small chunks of code. We no longer have these weird 7bit, 8-bit or 12-bit computers laying around. And that's bad.
It's bad because we are going from an intensive revolution into an extensive evolution. And we forget that there are still tons of fields that are still unexplored or badly explored. AI looks standstill, Robotics is nearly forgotten, technologies beyond the microchip look more and more as SF, Quantum computing as far as Quantum theories, neuron networks look as cracks in a barren desert. These are areas that demand bleeding edge ideas and methods, those same methods that gave rise to our modern computer world. Btw, on our OSS world we have a good example of the lazyness of modern times - look at Hurd and where it stands now.
Besides, because we are loosing the bleeding edge in computing, it is probable that we do not see nothing beyond the present languages, architectures and technologies. It is very probable that we may had a whole New World behind the present Ocean of Information. But to cross it, one needs some will and courage.
I've often thought over the last few years that we've made too little progress in making programmers more productive. I largely blame that on Microsoft, simply because it drives more software development with it's tools than any other entity. One language I've categorically made a decision to avoid is Visual Basic. I have always felt it was basically (sorry) a waste of brain cells. It has certainly done nothing to advance the state of the art.
In my opinion, one of the best things to come along in a long time is Java. The gentle reader may recall earlier posts along those lines. I enjoy C, and have spent the majority of my career doing C and C++. However, I have also spent _way_ too much time tracking down memory-related bugs. Often, they were in third party code. That is no way to run a railroad.
Java addresses almost all of the glaring deficiencies of C++, both in language design and in runtime safety. In my opinion, the best programming tools will be those that enable single programmers to tackle larger and larger projects.
Compared with C++, Java enables me to tackle much more ambitious projects with confidence. A team approach can never attain the efficiency of a single programmer approach. The "sweet spot" of software engineering efficiency is the largest project one person can tackle. Extreme programming is a useful hybrid that attempts to turn two programmers into one programmer. ;-) (Also teams can be nearly as efficient as single programmers if the system is properly decomposed into subsystems separated by simple interfaces. This rarely happens smoothly, in my experience. It takes a top notch group of people.)
One last note on Java - performance is now almost completely on par with C++. On my most recent round of benchmarks, Java (JDK 1.4.1_01) on both Linux and Windows outperformed C++ (gcc 3 and VC 6) on most tests. Dynamic compilation and aggressive inlining are that effective. The VM also soundly spanked the gcj ahead of time compiler in gcc 3. It thoroughly rocks to have truly cross-platform code that runs faster than native! Think how many religous wars would be avoided if 99%+ of software was available on all OS platforms...and think how much it would help Linux! :-)
If you want to see what's out there for Java, download either the NetBeans IDE project, or the Eclipse IDE. Both are free and each has its strong points. NetBeans is a Swing app and includes a Swing GUI designer. Eclipse uses a new open source "native widget wrapper" library from IBM called SWT which has it's interesting points. You'll also need a Java VM (there are also others available from IBM etc.).
One last thought - wouldn't it be cool if web browsers had support for something like Java? I mean, you could deploy apps just by putting them on a web page! It wouldn't matter what the target platform was! What a great idea! (This paragraph was sarcasm in case you were wondering.)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
... not software. There are a ton of systems/methodologies out there. All of them are valid IMHO. But you don't see the benefits because programmers simply don't rigourously adhere to any one of them. And why should they? Software engineering rarely has the impact that the older engineering disciplines have. Poor aeronautical engineering kills people. A buggy word-processor or game is irrelevant by comparison.
But the tools are out there to make a difference if you can motivate people, and yourself, to be more disciplined in the use of those tools; to give a damn about the end product. Learn to understand human nature and you'll see better code as you motivate yourself and your peers. And if you really understand human nature, I've found you can even influence managers and other suits to give a damn too.
"Consensus" in science is _always_ a political construct.
I don't think the key issue is "more quickly and more inexpensively developing software that's more reliable." Rather, I think it's developing software that handles change gracefully, because customers and managers are always changing what they want. Features almost never get removed from a product; and questions like "how readable, orthogonal, and well-factored is the code" become more important over its lifetime. These are human elements, not easily measured and it's not always possible to anticipate every change but it helps to try. Read the Pragmattic Programmer for some great advice about this.
Programming tools, development environments, and languages have gotten easier in the past 10 years. That does not replace good software design. Efficiency and serviceability cannot be added to a bad software project by switching languages or development tools. Only good design principles can make good software.
The Linux kernel, while monolithic, seems to be a great example of this...massively complicated, but easily broken down into parts that all fit well together and can be replaced easily. (And documented well...for the most part).
-ted
It's the clowns who are aiming the gun. "Foot, meet Bullet. Bullet, meet Foot."
In about 30 years earning my daily bread in the IT business there have been improvements. Lot of snake oil as well, of course. One thing that's stayed constant is that requirements get changed partway through development, which you can cope with in a small project with smart people and good tools. But in a large project it's a guarantee of cost overuns, late delivery, and angry recriminations.
Unfortunately, over the last few decades the environment in which applications work has become significantly more complex. 30 years ago much of IT was just a matter of shuffling data from one set of files to another: if you were a big organisation, you might even have a genuine database or three rather than just using files. Or you might be doing leading edge online stuff, which had it's own well-understood ways of doing things, one of which at the time was keeping the execution path lengths under control (yeah, we used to care about efficiency in those days).
These days, to serve up some information to a customer at home, an application might be running in a specialised enterprise-level java environment, communicating to some legacy big iron which holds much of the data and to other machines for specialist functions like authentication. All these interfaces have to be specified and implemented accurately for the whole system to work correctly and reliably, and it's still far too easy to miss the point at which a relatively well-understood project has slipped out of control.
In short, over 30 years, the proportion of projects that are large and complex and hard to coordinate has been increasing. In the circumstances, it's surprising that things work as well as they do.
For most modern languages, you spend a week learning how to use a langauge and then (potentially) months learning the (class) libraries.
I just started using Smalltalk again for commercial product development - it is amazing how little new code one needs when reusing already debugged and efficient libraries.
-Mark
Warning: I am blogging now: http://radio.weblogs.com/0115954/
There is no silver bullet, but having a good programming language sure helps. Of all programming language features, garbage collection probably improves programmer productivity the most. Anyone who has ever tracked down a stubborn memory leak or dangling pointer knows what I mean. Most newer languages (e.g. Java, C#, Python) have some sort of automatic storage reclamation, and it can be used with non-cooperative languages like C/C++.
When Y2K was getting ready to roll around, businesses spent billions of dollars ensuring that 30 year old code would handle the change of millenium.
Think about that!
How much new code, made with all of the zippy new tools in all of the latest and greatest paradigms, do you expect to be in critical use 30 years from now?
Big part of software development is often communication and interaction with the customer. Now it may be that in some of those countries many programmers will be fairly or very well versed in the languages. But not all will be, plus the distance and time zone problems will add to the communication and interaction problems. You just can't do everything over the phone and email, some things just need the engineers and the customer locked up in a conference room with coffee and a whiteboard, and flying people around the planet costs money and time too.
Sure, you may get cheaper software, but it won't be exactly what you want, or it won't be as effective a product as it could be.
Some jobs will move to the cheap regions, mainly the jobs (usually considered boring) that can be easily written in a spec, or that can be done by a completely separated team with minimal externally driven spec changes. Other jobs will remain available closer to the customer, and that is not just sales.
Basically, aided by the advent of open source software taking the role of commodoty software, this will mean that US and European programmers will relatively do a lot more custom jobs. A lot of the testing and bugfixing (QA), and supporting library development will probably move to the cheaper regions.
Actually, it should make the jobs a lot more fun to the programmers in Europe and the US.
--- Hindsight is 20/20, but walking backwards is not the answer.
Even though it won't earn me cool points for saying so, I know .NET has brought about a huge increase in productivity and scalability of apps where I work. We've rolled out several large and well-designed applications very quickly (2 months). Of course, you can always take the best tools and write bad code slowly, but .NET makes it easier to write good code quickly. If projects like Mono pan out, make that 'good, cross-platform code quickly'.
>I predict that very few people in the US and
>Europe will be employed to develop software in 5-
>10 years time.
And this is bad... how?
If your skills can be automated or easily replaced by cheap labour, then that's a pretty good sign you should change your skill set. This is much the same situation as that faced by the people you've displaced by writing code which makes their work environments 'more productive'. Never thought you'd see the same paradigm applied to yourself, huh?
Adapt or die. Those who are trying to keep coding jobs from becoming more cost-effective are little better than the Luddites who burned those first looms. There's more to CS than writing code.
Talking about System Integrators Industry...
For what I see, if we had the tools we have today with the requirements of 25 years ago, we could do fast and good software.
"Cheap, Good, Fast in detail"
Cheap: our marketing/management wants it cheap to get more money
------
More programmers? They'd be useful. I know about "The Mythical Man Month" but I know also about "Under-staffed Death March Project". But unless the project is already in crisis, the senior management won't give developers
Good: just the developers/end users want it good
-----
Sure the customer claims it wants a good product, but such a claim is not supported by realistic time requirements and superficial attention to the results.
Fast: the customer needs it yesterday
-----
I've heard a customer revolutionizing all the requirements for a project (when we were 60% of the schedule) changing the framework we should have worked on and telling "Give me you're new estimate, even though it is clear we won't accept any change of the release date"
So my opinion: the sw dev process has improved but hasn't kept the pace with the market requirements and senior management greed
This message doesn't need a sig
I think this happens because we lose sight of the problems we are trying to address with the software. In many ways, we are developing software for it's own sake (if you don't believe me, just look up some project failure rate statistics)
I predict that very few people in the US and Europe will be employed to develop software in 5-10 years time
That shows that you're incredibly naive and project every trend infinitely into the future. Firstly, apart from the fact that India mainly served as a development center at the peek when "Western" developers were just enormously expensive, since then it has faded largely away as an issue. Secondly, If software development were such an easy, external issue then there wouldn't have been internal software development in the first place.
Software development, and "brain" engineering isn't going anywhere. Prophecies to the contrary are the domain of the burger flipping jealous.
30 years ago I was programming in assembly language and had to code my own library of subroutines. You young whippersnapper programmers have it easy.
When I was programming I had to walk in three feet of snow on my way to school... uphill in the snow both ways... lard sandwiches... old rubber boots... carrying my younger brother...80 degrees below zero... aaaannnnd we had to use MSDOS on a 4.77 mhz CPU!
From excellent karma to terible karma with a single +5 funny post...
... and if it doesn't do everything you want it to do, implement the kitchen sink yourself.
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
COCOA! Formally known as NeXTStep. End of story.
In my experience many in the IT field fall into one of two categories: Those who do the work and those who make a living telling people there are better ways to do the work (this group usually correlates with people who couldn't actually do the work themselves). Reading your resume it is readily aparent what category you fall into...
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
Yep, it's improved. XML, Java, Perl, Python and Ruby are all slowly reinventing Lisp. This is a good thing, as it allows people to use Lisp without admitting it to themselves.
Sigh.
In a word, no. The major change in the last 20 years has been to commoditize the programmer. It isn't finished yet, but it is heading that way.
I guess you could say there has been some improvement. Software tools have developed to the point that you can hire a large number of fairly incompetent people and have them work together without it being a total loss.
The average coder this days is far inferior to the average coder 20 years ago. There are a lot more of them. And code quality hasn't improved a bit, perhaps it has decreased.
On the other hand we are building larger and more complicated systems.
On the gripping hand, a lot of the size and complexity is there for not reason but to deal with the problems introduced by size and complexity.
So it isn't a clear win either way, except for the managers.
Yes, exactly... except for the part about other engineering disciplines. ;)
The trouble with that phrase is that 'software engineering' isn't properly one of them... or is it?
Geeky modern art T-shirts
For the most part the industry has stagnated. Let's get real. This is a site that primarily is a haven for people who dislike innovation and who worship variants of an OS (Unix) originally designed in 1969 to run on a PDP-7 minicomputer. The languages espoused here are virtually all derivatives of C which was a quick hack developed at roughly the same time.
Even in 1969, C (and Unix) weren't state of the art. But, they were, mostly by accident, available for free to universities with little budget for their math departments. Hence a generation of coders who actually think that C has value.
Let's get real. A language with no concept of a string? A language with no concept of buffer validation? A language with enough precedent levels to keep thousands of programmers confused and making errors? A language with symbols and operators that mean different things based on context? A language with standards that actually consider order of compilation rather than requiring multiple pass evaluation? A language with case sensitivity?
These things were all obsolete in the early to mid 1960s. That C and its descendants continue to this day is both a tragedy and a source of shame for all of us yet we see few new languages that aren't designed to look like C.
Perl, Python, Java, LiveScript/JavaScript/JScript/ECMAScript, C++, C#, ObjectiveC are all children of a badly designed parent that inherited many of the faulty designs. Where is the new Simula? Where is the new SmallTalk? Where is the new PL/I? Where is the new GPSS? Where is the new Algol? For that matter, where is the new BASIC?
We have built a million really great world class products in 3 days because of .Net. It's like visual basic for real programmers.
The real secret is faster processors. The faster the computer, the faster the development.
No, not really.
Pr0n.
1.) Back then, you had a zillion platforms and things where much more experimental. Today you get x86 whereever you look. It's become <i>the</i> standard plattform for developement.
2. )Todays comps are <i>fast</i>. And I mean really fast. Things like my favorite Editor JEdit (www.jedit.org) are actually usable with todays standard hardware, even though it is a hideous chunk of OOP stuff running on top of a VM. In five years from now no one will give a shit what processorpower an app will need, as long as the Framework is easy to use, OOP all the way through and extendable within hours.
3.)Rocksolid OOP packages that have years of expierience and expertise in high level softwaredev behind them. Just think of Java or it OSS 'counterpart' Python if you will. I programmed a simple Inet-Agent with it's own HTTP socket within a few hours the other day. I didn't even bother of using wget as an external programm, because it would even have been more difficult(!!). Think about that. No way would have that been possible 10 years ago.
You have you're libs that can be bound into any PL you can think of within minutes, you have entire Application Servers that will install with 2 mouseclicks (ok, maybe three...) and have you're project rolling 10 minutes later and if you know one PL good enough it usually takes you round abouts 3 hours to get rolling with a new one because they all follow the same tried and true principles that have proven the to be the best. And if you only keep you're eye on it a little bit you're bound to have zilch hassle in migrating or porting to another plattform.
Yes, Softwaredevelopement has developed from an exotic experimental thing to a fully grown science and profession, with all the benefits that come along.
We suffer more in our imagination than in reality. - Seneca
is what counts most. With experience also comes the ability to work in a structured fashion. It doesn't really matter what structure you follow: OO, State Machines, Waterfall Development... as long as you adhere to whatever process you have in place and not work in a haphazard fashion.
Fancy programming tools and paradigms don't help much, but revision control and requirements tracking do help a lot.
Last but not least: Test, test, test and test again...
For a construction project all of these elements are mapped out well in advance, which is why the construction industry can work on lower margins.
Ah, the inevitable comparison with the construction world... Just keep in mind how many of the larger construction projects (focus is on the larger projects, because the problems for software development are also on the front of the larger projects) are delivered on-time, on-budget.
The difference between contracting out to an Indian IT farm and hiring a great programmer -- from any country -- is rather akin to the difference between employing 100 monkeys and hoping one of them will bang out Hamlet, and hiring William Shakespeare.
The truly brilliant programmers are few. And pretty expensive. But they're well worth it.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
... Lisp development environments in 1980? If Visual Studio is an example of progress in the last 20 years, I'm impressed... NOT. Every one of those features was in every commercial Lisp development system of the era (Symbolics, LMI, Xerox), along with lots more. And, they live on in the ilisp development environment, which gives them to many Common Lisp and Scheme implementations.
Yes, this is flamebait. Yes, I'm bitter and curmudgeonly. Perceptive of you to notice...
To a Lisp hacker, XML is S-expressions in drag.
I first started writing code for money in 1979, for McDonnel Douglas. Let me tell ya, things have gotten WAY BETTER. In those days, we wrote Fortran using IBM's TSO (TSO - Time Sharing Option). We didn't even have EMACS! We had crappy "line editors". We used those old Tektronics "storage tube" displays that could display graphics, but only static vecter images, or we used VT100's. There was no such thing as an IDE and compiles were "jobs" you "submitted" to the OS using Job Control Language. Oy, it was a pain.
OOP and IDE's and source code control and project management tools have all gone a long way towards making programmers much more productive. We've advanced hugely.
This doesn't translate to less buggy products, however, because increased productivity just means that more is expected of programmers. The products we work on are huge now and much more complex. The one, main underlying rule of producing software products hasn't changed and never will:
You can have it good, fast or cheap, pick any two.
If you haven't tried Visual Assist, give it a shot - 30 day trial, and it's awesome at helping out those who are used to VC++ but need a bit more quickness and functionality when writing C++ stuff in Win32 environments...
Sorry for such a blatant plug, but I have recently purchased it after a demo, and love it!
Any sufficiently well-organized Government is indistinguishable from bullshit.
Is software better (i.e. easier to use, more powerful, more detailed) than it was in 1975? Yes. Is that improvement driven entirely by the changes in hardware? No. Have programmers as a group gotten significantly smarter in the interim? Probably not. Ergo,
A few of the things that have made for better software development are:
The essence of the human condition is a desire to improve the environment, and I believe that drive is strongest in scientific and engineering disciplines. It's only natural, then, that 25 years of labor by millions of relatively smart folks has resulted in some significant improvements. It's also only natural that we continue to look for ways to improve things, rather than saying: "Okay, we're done! These are the software development tools, and they're not going to change any more from here on out."
heh, I pull up the comment page for this post and what advertisement do I see?
.Net
Microsoft Visual Studio
Ironic?
I have often regretted my speech, never my silence.
-Xenocrates
I've been a programmer for 16 years, and I've seen no real improvement. Throwing up a skeleton UI is certainly easier, like in VB, but in large applications the toughest work is still in the middle and on the back end. These are the areas that require sound mathematical and algorithmic principles, such as those expounded by Knuth. These days it may be easier to keep track of objects and components, and get F1 help and documentation, but someone still needs to write the guts.
Johnson and Rich were also proponents of having Lockheed engineers maintain their aircraft instead of having military personnel do it. Using Lockheed engineers would save a ton of money because they aren't rotated and therefore don't need to be retrained. Sure, Lockheed would get some money out of the deal, but not as much as the gov't would save.
The Skunk Works wasn't perfect, but overall they were pretty good with money under Kelly and Ben.
> ...and I keep wondering what "improvements" ...
l
> have actually brought progress to the key
> issue: more quickly and more inexpensively
> developing software that's more reliable?
Your question has more aspects that one would realise:
1) The realisation that reusable packaged components are a boon to development.
2) The realisation that during development of a large project, one can produce reusable components as a spinoff resaleable develop that adds true value to the company (by value of the asset.. whereas a customised application is typically worthless to anyone but the company that requires that specific set of customisations).
3) The actual resale of those developed components through mass market repositories at REASONABLE prices.
4) A culture of purchasing components instead of developing something simple ensures ownership of a non-core problem (maintainance of a component) is not the responsability of a company whose business only requires the usage of said component. A number of component companies price their components and support costs outside the range of small businesses... which is a shame.
5) Open Source repositories of reusable components is an evolution within the world of software development.
---
Software, tools and components that provide massive improvements in TTM (time to market) for small projects are possibly insignificant when taking into account large projects but a quick summary would be:
The various middleware and appropriate environments allow a developer to develop and deploy solutions without developing those lower software layers (eg: JSP, SQL Server, Websphere, RMI).
In my opinion, with more companies developing reasonably priced, stable and secure infrastructure the more one can reasonably engineer a reasonable solution.
A brilliant example is the infrastructure developed by Borland:
For small projects, the biggest boon to developers is reasonably priced components for GUI development environments such as C++ Builder, Delphi, etc.
Drag, Drop, connect a few dots, Run.
True engineering.
---
There are some hazards one must realise. Many software companies are setting the industry/world economy up for a typical downfall by destroying the companies that support them. They do this by over-charging for products. MS, Oracle, IBM, etc are common examples.
They charge monopolistic rates and take large profits for the use of their engineering services at the cost of the longterm viability of the economy as a whole. With large taking excessive profits, they reduce the expendature that real companies can use to grow their business. Money is centralised in software companies which ONLY facilitate other companies to do business. They do not ensure profitability of real businesses.
This is why ALL IT companies, IT departments, etc, are not profit earners because they do not conduct business, they only facilitate it, optimise it. Being able to make transactions, does not imply that one will give a company money because its got a good set of servers. I want fruit and dont care about your lovely pair of servers.
So, our view of IT isnt too good at the moment.
====
The next major development boons will come in the project management field but it will have limited development benifits instead improving the maintainence and formal validation of engineered software.
Realise that developing software is (as someone said somewhere... not sure who) akin to developing a new theory of relativity every time you write a new program and that its easier to explode and manipulate a 25m x 25m square of reinforced concrete than it is to radically adjust and transform a program into something that has an improved framework.
Typically, once you've chosen your framework and added functionality to a software application - you've locked yourself into a framework paradigm its difficult to change your framework without a total rewrite.
==============
So... considering project management:
Various environments and languages need to come up with a common framework and process description as output by the language compiler at the time of object code compilation. This need is based upon the realisation that there is no language and environment that suits every need. Html, Perl, Python, Java, C++, Smalltalk, Assembler, Natural, Cobol, JScript, ASP, XML, XSL, etc - all have/had their need and provided the best solution to the problem at the time of the initial development of various solutions. To compound matters further, the various environments are probably fractured hybrids of many environments. Eg: JSP frontend with a backend group of application servers connected to a database server and possibly a rendering/computation farm in there somewhere. All that connectd by various perl, shell scripts, corba, PL/SQL, java, c++, libraries, etc.
The need for a consolidated project management view that is able to analyse, verify and formalise every aspect of a large system is the next evolutionary phase of software development and project management.
This will only happen with compiler writers developing a common.process.description output file that can be consolidated by a single project management tool reading the outputs of many different compiled outputs.
This would ensure that the task of analysing source code the responsibility of management tool developer (he'd go out of business before analysing in detail various languages) but rather the compiler writer (who is the only person who can truely formalise and describe the processes that his compiled output will execute based on appropriate input source).
If this ever happens, it would be paradise in binary.
====
So, your typical bane of any project is either an inappropriate project development paradigm and inappropriate project management tools that provide little real value to the developer/engineers and are more of a token of accountability for management to disclaim responsibility by implying that the developers/engineers are not developing according to schedule when managements theory of relativity ends being relatively different to the theory of relativity that is possibly concievable by developers.
Its funny that my views intrestingly correlate with real life:
The cost of project failure is then typically carried by shareholders/ investors/ owners and as a result the company performs badly and the economy is weakened as inflation rises.
"
http://theregister.co.uk/content/7/28299.htm
IT project failure is rampant - KPMG
"
Yes - technology has advanced.
Yes - various tools are easier to use.
Yes - vendors are more easily able to make available certified components.
No - there is nothing significant that improves the actual programming of complex projects outside the leveraging of infrastructure frameworks. Please show me something significant.
-Tim
The problem with Java's performance issues when it comes to inheritence isn't the inheritence itself; it's the way java handles it. Couple that with what is essentially interpreted code (ducks from the Java purist flames), and you've got a big performance hit.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
Im also in a Computer Science Degree program and just from what I have observed through lectures, labs, and a couple of internships, I would say the biggest improvements have not come in new languages or development environments, but in the software process itself. In 1994 81% of companies who's software processes were reviewed using Watts Humphrey's Capability Maturity Model, rated at level 1, which means they had literally no software process, no QA, metrics, nothing. By 2000 that number had dropped to 35%. Companies figured out that a decent software process helps to reduce costs, produce a better product, and realize schedules.
Le BASIC nouveau est arrivee!
http://www.realsoftware.com/
Not sure if it was invented by college kid, but AOP seems pretty promising:
aosd.net
Take some programs from the late 70's early 80's. Do you have any doubt a talented programmer could knock out something like Visicalc in about a week using modern tools? How about a simple flat file database system?
Programmer effeciency has skyrocketed. The applications being designed today are much more complicated than those of 25 years ago.
Seen XP work with 4 people who were very good. Saw it fall flat on its face with 16 average people.
As all the XP books say, XP doesn't scale.
An Eye for an Eye will make the whole world blind - Gandhi
There definately seem to be some improvements for the developers: API's, Frameworks, Libraries, Methodologies, Languages, etc... All help the developer build apps faster and easier.
For the end user however things have gotten worse, since much of the above mentioned things are flawed and unoptimized (note: this is a generalization, there *are* exceptions). Eventually most of the flaws get worked out (except there are a few cascading bugs which will likely remain), however efficency sucks, and rather then optimize developers rely on faster computers to make up for the lack of optimization. I'm not even talking bloat here... just pure execution. WP 5.0 was rediculasly more effcient then Word XP and did everything I need in a Word processor today.
For the future things should improve. People have stopped the silly upgrade cycle of computers, and more and more development is moving towards embedded devices where is becomes a competitive advantage to go back and focus on optimizing code.
--- Nothing To See Here ---
I wrote my first computer program in 1974 or 75 and have been a professional programmer (meaning that I got paid to write code) since '79 or so. School was mainframes and an early Wang desktop system (Basic and punched cards, oh yeah, baby!) I later moved into minis, mainframes, and I've been working with desktop systems since CP/M and the S-100 bus, so I guess I've seen a little of the history, anyway.
In my experience, the actual process of coding has greatly improved over time but the process of developing software hasn't improved as much. As other posters have pointed out, object-oriented tools, technologies and techniques (among other factors) have greatly facilitated the generation of code but the management of the process; deciding what gets coded, when, by whom, etc. is little better now in actual practice than it was in the late 70's or early 80's. In fact, in my opinion the situation is in some respects worse.
Management of software development today makes the same mistakes and operates under many of the same misguided assumptions as it did back when I spent my day in front of a dumb terminal. Adding outsiders unfamiliar with the details of a project makes the project later, not earlier, etc.: all the platitudes we know and love are still with us, still the butt of Dilbert jokes.
Technology may change; people aren't quite so amenable to upgrades, I think.
I think that one of the great ideas that has come to us from mathematics is the Abstract Data Type. With its seperation of logical view from physical implementation. That is describe the functional service in it minimal essence. Then you can implement it any which way without breaking things.
That was the important idea behind Databases. and why we adopted Databases quickly even though they cost more in terms of time space and money. It was a realization that this meta model of design solved the maitaince problem that was threating to bring down Computers as a viable business tool.
The second big one came from normalization of databases. Which solved much of the maitainence problems with data storage and handling. This came after Databases.
Then there was Modulo which allowed segmentation of software into computational units, a first step to implementing ADT's.
Then we brought these together in OOP with modular normailzed data and programs together. All part of a march towards a natural evolution of compact maintainable systems.
With the next round which seems to involve efforts like J2EE and others with allowing software to talk seamlessly over networks as just part of what they do. We are starting to abstract out even the computer hardware underneath.
Who knows what evolution will decide is then next great idea. Where we will end up doing our work.
I just hope our economy lasts long enough for us to realize the next step.
From what I've seen over the last 15 years, any shift in IT/engineering personnel supply and demand has largely dictated the importance and enforceability of disciplined approaches to problem solving. At this point in the state of things, everyone is at least buzz word compliant and talks a good game. The real issue is getting follow through. I've found that when engineers appreciate their jobs (especially if there are not as many around), they are much better team players and more easily controlled by management that understandably wants to be able to predict the outcome of a project and leave behind more than a few bread crumbs for maintainers to follow. During the dot com era, I saw many arrogant developers that held management hostage with threats to leave if various conditions (salary, snacks, choice assignments) were not met. These same developers very rarely functioned well within a team - there were many "personality" issues within "engineering" (code slinging) groups. With the dot-com era over and the subsequent decrease in demand, management once again has more control over the process. Now to find some strong technical management . . .
Hi! Happy Tuesday! I have to say that estimation of projects is still 100 lines per day per developer. As hardware has gotten more sophisticated so have software tools. In the end we are right back where we started, 100 lines of code per day. Call this Brook's law, "The advancements in hardware and software offset each other such that productivity remains a constant 100 lines of code per day per developer."
NeXTSTEP, OPENSTEP, OSX, Objective-C and Interface Builder.
Nuff Said
I've been a developer for half of those 25 years, and I think the most important improvement has been in the IDE - the Integrated Development Environment... Borland's always had the best (IMHO, but perhaps I've simply grown used to their IDE). Features such as CodeInsite (press CTRL-Space to see an objects methods and procedures - and in Delphi 7 just the ones that make sense in your current context even inside of a WITH) and a Debugger (with useful features - ability to set Breakpoints with conditionals for example). There's nothing like tracing through logic as it's running in the IDE when you're in the guts of development.
Will people please stop using this phrase!!! It is driving me nuts! I nominate it for the most overused phrase of the last 10 years (not to mention this slashdot article)
There is no silver bullet for a phrase that is the silver bullet of..oh, never mind.
You don't hear much these days about the "fifth generation" computing projects that Japan was spending a lot of money on back in the early '90s, do you? This is why.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
Just write some damn code. Why does everyone want things easy?
"No Silver Bullet" was included in the famous book, The Mythical Man-Month, as most or some of you know. The newest 20th anniversary edition includes both "No Silver Bullet" and "No Silver Bullet Refired", an introspective look an how software methodology has improved over the last 20 years. I don't mean to sound pompous, but while some of you have talked of your experience over the last 20 years, Dr. Brooks was already a project manager at IBM working on operating systems 30 years ago, so the man assuredly knows what he's talking about.
Admittedly, I can't comment on Dr. Brooks' latter essay, as I bought the book myself not long ago and just finished "No Silver Bullet" (the last chapter in the original version of the book), but it still makes for interesting reading. Pick up a copy, or just even sit down at Borders and read both chapters, I promise you'll be intrigued if you're interested in software development.
--- What
I fully agree. Java is a really sweet language, and I enjoy using it, but it's slow as hell even on some simple things like scrolling.
There are lies, damn lies, statistics and the over application of Mark Twain's complaint.
Unfortunately, since things have been so bleak professionally lately due to all the 'help' received by US programmers it may be left for someone else somewhere else to complete this work.
Seastead this.
Has software develpment gotten better? I am not sure but I can say the amount of info available online to complete a software project has gotten better. The web sites, bulletin boards, and so on are packed with info on any language that was not so easily available 20 years ago.
A hand up and a foot on every chest...
A hand up and a foot on every chest...
[no body]
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
It's like asking "Has art improved?" because programming is an art, even though there are elements of science and mathematics.
:-)
To drive home the point further, I tried getting slashdot to mail me my password, but I got an internal Web server error... someone please mod this up to +1.
It sure as hell has not gotten any easier to do software development in the past 20 years.
What I find ironic is that we spend most of our time solving the same problems over and over and over again, just using some new language and/or methodology to do it.
(oh sh*t, I just gave away our secret...)
I work for a Fourtune 500 company (intern) working with a software & hardware development model. The model that we use constantly goes through changes and is very sucessful in terms of delivering software and hardware on time, and defect free. I have no clue about budget, but I'd guess that it is not over budget either. Working here has given me a favorable view of software engineering. Every process is laid out and explained, and there are many tools at our disposal, including a requirements tool, a UML tool, code generation tools, code testing tools, etc.
Now for the rant. I also go to a large University 20 miles down the road, and I am taking their software engineering course (<- yay for relevance). Among CS majors there is a bad reputation for the SE class, that it is never organized well and leaves students with a bad taste for SE. In my class, we are currently in the 'Design' phase for our semester-long project, we will be done tomorrow. The Implementation phase is a week long. That's right, a week. We spent months on the requirement and ooa phases, but they are still unclear (because the document that calls for them is unclear), and now we have a week to iron everything out. This class leaves me with an unfavorable view of software engineering.
I think that more colleges should teach software engineering not as just one class but as an approach along with code classes. It makes sense when teaching people how to code that one should also teach them the likely environment in which they will code, otherwise students will get the impression that they can opt-out of having to deal with software engineering.
Has software engineering become better? Probably. Would you be able to tell when taking the class that I am? Hell no.
Looks like your painter doesn't have a good specification to work to, or hasn't been 'empowered' enough to ask for one.
ALWAYS blaim the management.
thank God the internet isn't a human right.
All the blood, sweat and tears put into your programming masterpiece will be undone by your bonehead boss who hires some schmuck who looked good on paper. All the diagrams and CASE tools won't save you from your team members (or even yourself after a few years, many beers, and grey hairs).
You can either stay in the trenches and live with this inevitable truth or move up the food chain and pray that you know how to hire like-minded developers.
Ah, I remember the school days. It seemed so simple then. Who would have thought that the programming field would be so torn with politics, moron team members, and pointy haired bosses. It's never going to get easy, but that's a good thing.
Hecubas
I completely disagree, stay in, get your degree. I've found many non programming jobs which have wanted a CS degree probably because the HR person thought it would make them better to fix a server. I do think you should get it and you probably won't regret it. You want every advantage you can get and a degree is a great one.
..this is but a fantasy..
but thanks for playing.
That's the old BASIC in a new version. The new BASIC would be a language designed for beginning non-programmers to get an idea of programming concepts in a SIMPLE, friendly environment.
Compare Dartmouth BASIC running on its interactive time-sharing terminals to batch Fortran on punch cards to get an idea of what a revolution it was at the time.
Of course software development has improved,
Security is at the heart of the Windows' design - It is so bloated, unstable and slow that no hacker ever gets a chance. Now you know why it got C2 certification.
GNU Software, GNU/Linux, and FreeBSD have been
the MOST significant improvements in the last 25
years. Peer review and Free Software ROCK!
To the person that writes "more quickly and more inexpensively ...", here's one tip: in Lisp, you don't need to say "( ( (" when "(" will do.
Actually, it is those people who rely on the wizards and IDE features that tend to produce code that scales well with the project. One smart-but-naive programmer of ours started building a Win32 application. As requirements got added, he realized he needed to make it more "modular." As he did not understand the full workings of MFC, he opted to create his own MFC-like library. Eventually, a thousand bugs cropped up and he left the company in proud frustration. "Idiots" he called us for suggesting he move to MFC or VB for the UI (WinForms wasn't around back then). Had he used the built-in IDE features for GUI creation, he'd automatically have inherited Microsoft's best practices and we'd have gone through a lot less trouble.
Plus, it sucks when a prima-donna like that ends up taking a week just to add another button.
You should duck from the Java purist flames because you and the poster you're replying to are wrong. Java hasn't been interpreted for years. All Java virtual machines use some sort of JIT mechanism to compile the code before its run.
My blog: http://jkratz.dyndns.org/~jason/blog/
The idea of course being that good modular design, and good use of classes can increase reuseability ad infinitum, so that eventually there will be no task and no problem that cannot be assembled lego-like from blocks of premade reuseable code. The marvelous technology in Douglas Coupland's Microserfs ( called Goop wasn't it ? ) was really the epitome of this concept, a totally reuseable code system that was so generalized, so modularized that anyone with no more experience in programming than a child could assemble working programs for just about any purpose in a drag-and-drop virtual lego-building reality.
Any student of the history of science and science forecasting should begin to smirk at this point. Is it any surprise that these visions have not materialized? The hard truth, IMHO, is that logic is inherently not conducive to such high degrees of abstraction and modularity. For given tasks which are fixed and well defined with completely known and understood parameters and requirements than yes, abstraction and modularization can be a great boon in optimizing design and improving the development cycle. We can see the great advantages that this has yielded in some areas where the requirements are fixed and the applications are mostly derivative of each other. GUI design is a great example, and there are a multitude of GUI building toolkits & development environments that take great advantage of this.
However the whole thing breaks down when you move from the known to the unknown. When you try to extend this principle from fixed tasks to hypothetical ones in which the basic requirements are not envisioned. I would argue that there is a basic lack of understanding among some of the proponents of these techniques that at a fundamental level logic cannot be generalized out across all possible tasks, and all possible configurations. This was similar to the revelations of Godel's theorem in mathematics already in the 1930's - that any axiomatic system could be consistent but never complete. In reality adapting one set of code to a purpose other than that for which it was designed, or with parameters other than those originally envisioned usually is more trouble than it is worth, and often you would be better served by building new objects from scratch. You will always need intelligent educated people to design these things; there is no such thing as logical lego.
Unfortunately it seems to me that many have not gotten this message yet. Sun and Microsoft are still actively humping that dream of infinite modularity and drag-and-drop programming design. In my experience with both Java and .Net, I have found that I always run into blocks where the established object model is too constraining and has too many built-in assumptions about what you're going to be using the classes for, and so I have ended by coding new versions from scratch. Of course it may simply be the nature of the applications I'm working on, and your mileage may vary. Ultimately I think that for derivative applications this kind of abstraction and generalization is definitely an improvement, but when you come to applications that move beyond those fixed tasks it actually becomes an impediment not an advantage.
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
All the skunk works did was cool hacks. And like software hacks it got the job done in a fast and dirty way, but in the long run their products were unworkable. The SR 71 Leaked more fuel than it lifted. Thats right, they blew-off all thermo issues and said, "who cares that it leaks like a sieve on the ground, it'll heat up at Mach and the pipes will expand and stop leaking." This is the Aero equivalent of not checking for a null handle on a malloc. Sure it'll work most of the time but it;s sure to blow-up on you. Lockheed did some great research with the skunk works, but they never delivered a product. Sure you can build something flashy real quick with VB, but would you want to fly in a play controlled by it?
The software development process has greatly improved in the last 5-10 years. While software hasn't specifically gotten all that much better, the processes for producing good software have been advanced.
Here is my list in ascending order;
1. The Internet and the web. Access to resources like USENET archives and online vendor documentation have greatly improved the development process. For example, a defect in a popular Java Application Server was causing me considerable difficulty, and a quick check of the vendors website indicated SP1 would fix my issues.
2. Acceptance of high-level interpreted languages. While Smalltalk tried to make this happen, it wasn't until Java, Perl and ASP (VBScript) that this trend became popularized as computer hardware started catching up. Developers no longer have to author their own implementations of String(), and many other common functions are readily available.
3. Object oriented development.
4. The relational database server and ANSI-SQL. Developers today are versed in the methods of normalization, and dependencies on home-grown datastores has virtually disappeared.
5. Modular / packaged code. While this isn't a recent development, it has become a best-practice and this has greatly improved the development process.
6. Revision control best-practices. There are still many organizations who version sourcecode using a copy command, but the vast majority of pro shops now use some form of source code control.
7. Open source software. IMHO, this is key to the next wave of development and it has already had an enormous impact.
A variety of software development lifecycle models have helped professional developers learn how to manage projects, but this still needs work particularly from the perspective of management. It's quite possible OSS will obviate the need for many ongoing commercial software development efforts, and while the last decade has been about software teams getting bigger the next decade can really be about the team getting smaller.
Once the teams can leverage existing OSS code, wheel re-invention becomes less necessary and code can be written under-budget (cheap) and on-time (fast).
Eric Sarjeant
eric[@]sarjeant.com
Which is why I added the keyword "essentially". I'm aware of JIT compilers, and their limitations. But when you boil it down, you're translating bytecode into the current machine's code, and that takes extra time to do.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
I am still mystified that a discussion like this can take place and the system which Donald E. Knuth created to enable him to write TeX (www.tug.org, see the book, _TeX: The Program_ for the pretty-printed source) and METAFONT (_METAFONT: The Program_) is almost never mentioned.
t .w.gz (with an offer of a $2.56 reward check if one can find a bug), or as a document to just read here: http://www.literateprogramming.com/adventure.pdf
DEK has since written an entire book on the concept (_Literate Programming_ a CLSI series book) a decade ago, but one seldom sees source so provided.
There are some really cool example programs which're quite interesting (and educational) to read, for example:
Will Crowther's game Adventure - available here: http://sunburn.stanford.edu/~knuth/programs/adven
Or a CWEB version of the RPN calculator for K&R's C Book: http://www.literateprogramming.com/krcwsamp.pdf
Probably what really needs to happen is a way to post a program as a web page, then to click on a link on it, to automagically compile and run it....
William
Sphinx of black quartz, judge my vow.
Realise that developing software is (as someone said) akin to developing a new theory of relativity every time you write a new program and that its easier to explode and manipulate a 25m x 25m square of reinforced concrete than it is to radically adjust and transform a program into something that has an improved framework.
Typically, once you've chosen your framework and added functionality to a software application - you've locked yourself into a framework paradigm its difficult to change your framework without a total rewrite.
=====
The above is a fundamental hurdle to all software development.
We typically get about 3meters up this pole-vault by using various infrastructure environments that are a boon to developers - JSP, SQL Server, SAP, etc. They ensure that the developer does not need to reinvent the wheel. The boon of reusable components is modern computing.
===
Problems with IT businesses are their lack of extracting resalable components from their software. Customised software is effectively worthless to anyone else other than its intended recipient. Reusable components have a real value to many companies.
===
A brilliant example is the infrastructure developed by Borland that promotes engineering:
C++ Builder, Delphi, etc:
Drag, Drop, connect a few dots, Run. - True engineering.
===
The next major development boon will come in the project management field but it will have limited development benifits instead improving the maintainence and formal validation of engineered software.
Various environments and languages need to come up with a common framework and process description as output by language compilers at the time of object code compilation. This need is based upon the realisation that there is no language and environment that suits every need and so there are many different languages and environments eg:Html, Perl, Python, Java, C++, Smalltalk, Assembler, Natural, Cobol, JScript, ASP, XML, XSL. They all have their purpose but make it difficult to coordinate and collect information in a single project management tool that has real value. Taking observations further one will notice that projects often use many different environments and are fractured hybrids.
Eg: JSP frontend with a backend group of application servers connected to a database server and possibly a rendering/computation farm in there somewhere. All that connectd by various perl, shell scripts, corba, PL/SQL, java, c++, libraries, etc.
The need for a consolidated project management view that is able to analyse, verify and formalise every aspect of a large system aswell as any meaningfull application by software developers/engineers is there, but nonexistant. This will only be realised when compiler writers develop a common process description that can be consolidated by a single project management tool reading the outputs of many different compiled outputs.
This would ensure that the task of analysing the source code is not the responsibility of the management tool developer - he'd go out of business before analysing in detail every appropriate language - but rather the compiler writer - who is the only person who can truely formalise and describe the processes that his compiled output will execute based on appropriate input source.
====
Your typical bane of any project is either an inappropriate project development paradigm and inappropriate project management tools that provide very little real value to the developer/engineers and provide more of an accountability token for management to disclaim management responsibility by implying that the developers/engineers are not developing according to schedule when managements theory of relativity ends being relatively different to the theory of relativity that is possibly concievable according to a reasonable schedule by developers.
an intresting read:
"
http://theregister.co.uk/content/7/2829
IT project failure is rampant - KPMG
"
===
There are some hazards one must realise. Many software companies are setting the industry/world economy up for a typical downfall by destroying the companies that support them. They do this by over-charging for products. MS, Oracle, IBM, etc are common examples.
They charge monopolistic rates and take large profits for the use of their engineering services at the cost of the longterm viability of the economy as a whole. With large taking excessive profits, they reduce the expendature that real companies can use to grow their business. Money is centralised in software companies which ONLY facilitate other companies to do business. They do not ensure profitability of real businesses.
This is why ALL IT companies, IT departments, etc, are not profit earners because they do not conduct business, they only facilitate it, optimise it. Being able to make transactions, does not imply that one will give a company money because its got a good set of servers. I want fruit and dont care about your lovely pair of servers.
===
-Tim
Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.
2002 - 1987 = 15 years
Yes...it takes time the first time through the code. Big whup. There is definitely a trade-off when using Java but then again nobody ever said that Java had to be used for every project. Someone else posted about how slow Java is even scrolling. They're full of crap. The machine I'm currently using is a P3-500 with 256mb of RAM which is not by any means a speed demon and I use JEdit exclusively for coding. Scrolling is not slow. It would seem that most people saying that Java is slow probably haven't actually used Java in years.
My blog: http://jkratz.dyndns.org/~jason/blog/
It's pretty easy to outsource system management - just sign a contract and forget it.
On the otherhand, a huge chunk of IT programming is customer interfacing and requirements gathering. That will always be inhouse.
As for programming itself, it's now common to put together many megabytes of code. In the 1970s, you couldn't make anything that big work.
On the other hand, we have a major cruft problem. We're still living with design decisions from the early days of DOS and UNIX. They're hidden under layer after layer of additional structure, but they're still there, warping the architecture. C++, X-windows, MacOS, and the Win32 API are good examples.
Although it's less realized, we also have a hardware cruft problem. The PC of today is a warmed-over version of a much smaller machine designed for a much simpler operating system. Although today's PCs are far more complex than the mainframes of the 1980s, they don't have a mainframe-type architecture. The big problem is in I/O - I/O isn't channelized, as it is on mainframes. The lack of uniform channelized I/O means that drivers are at too low, and too privileged, a place in the operating system. Thus, every new driver is a source of system instability. Even though the hardware is slowly becoming channelized (SCSI, USB, FireWire), the operating systems have a low-level driver model. So we have scanner and printer drivers that can crash the whole system.
But at least the ISA bus is gone. Finally.
The other big change in programming, although I hate to say it, is the rise of "scripting languages". Visual Basic, Perl, and their lesser competitors have made programming more accessable to the many, and less risky. Yes, many of their basic features were in LISP and Smalltalk a quarter-century ago. But the syntax of LISP turned too many people off, and Smalltalk somehow didn't quite make it. What makes a good scripting language is an interesting study, and it's worth reading Larry Wall on this, whether or not you like Perl.
Yes, I think things have improved.
.Net Beta 3 to generate controls, will understand what I mean.)
Such things as Structured Design, and OOP have made coded reuse better.
What hasn't improved:
1) Programmers STILL refuse to use tools that could help them in productivity. (i.e. source debuggers, instead of writing printfs around everything and printing out your variables)
Tools tools TOOLS people. Use a source debugger and save yourself a great deal of time.
If you can't use a different language or infrastructure to write the code.
Sadly, many programmers still do not use source debuggers, citing a waste of time. But they will sit there and hack over and over again trying to understand the code they write with printfs!
Tsk tsk.
2) Cost Time Estimation. Wow, talk about almost zero improvement there. Almost zero, but not quite zero. After all, most people are now adopting an open source strategy so that even if your estimates are off, the cost penalties are reduced. Furthermore, most people are beginning to realize that you have to complete a full requirements document, and do some fact finding before you attempt to quote work.
3) Finally, the hardware we use to write software is vastly more powerful, and as a result we can run much nicer environments on our machines when we write code, such as API references, etc. I have far fewer references now days to things like Java for example than I use to have to keep on my desk. Primarily because with the rise of IDE's the development environment can answer alot of questions I might have about the language I am using to write the software with.
---
I would also like to point out things have got a little worse. If you believe like I do that 80% of the work in writing software is debugging it and maintaining it over its lifetime, then you like me have problems with our IDE's.
Primarily when our IDE's produce automated code for drag and drop environments. They produce horrible code, at the expense of saving time now, and end up costing a great deal of time later.
(Anyone use the latest
I primarily write only Java code, but even my SunONE environment produces some pretty cruddy stuff if I am writing a desktop app.
I think automatic code generation is a step backwards in many ways, and ends up costing more money to fix or maintain it.
I still think a code "repository" built by humans, and nicely documented, like a cvs tree for example, is the better way. Time spent on the CVS code repository for building customized pieces is time much better spent IMHO.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
Look at the software written twenty five years ago, and look at the software written recently.
Bill Joy wrote vi pretty much by himself. Bram Moolenaar write Vim pretty much by himself; it's a huge superset of Joy's editor.
The original portable C compiler (PCC) was about 5,000 lines of C. No one even blinks if a graduate student writes a far more sophisticated language processor, e.g., a C++ compiler, a complete Java development environment (including a compiler and debugger).
The original SimCity was awesome. No one thinks twice of re-implementing it for a PDA or a Java-enabled web browser.
What's changed? Programmers don't have to worry so much about CPU, disk, or memory limitations. The tools (compilers, libraries, source control) are much improved. Some of the new languages are far more productive. There are also new practices, and the results of lessons learned, on how to do development; some programmers take advantage of these (not enough!)
But our abilities haven't kept up with our aspirations. Compare SimCity to the masively multi-player Sims Online. How do vi or PCC stack up against Eclipse? Look at the text formatters of twenty five years ago, and then look at OpenOffice (or Microsoft's stuff); at Unix v6 vs. Max OS X.
Software hasn't kept up with Moore's Law. We're running a Red Queen's race, going as fast as we can just to stay in one place; and we're losing.
Stupid job ads, weird spam, occasional insight at
I have no interest in getting into a flame war over this. I have never claimed that Java is a bad language; I code in either it or Python (depending on what I'm doing) almost exclusively. Let's just say "we're both right" and move on.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
When I first found C/C++ in my freshman year of college, I was in love. It just made sense with the way my mind worked at the time, and I could just hammer away and make good working code quickly.
A year later I found Python. All those things you want, quick development time, limited bugs, etc., I have found to be accomplished through the use of Python. I've written high-speed socket servers, GUI applications (with wxPython), console email readers... So many things that all work well, and I spent more time writing them than debugging them. And writing them took 1/10th the time of C/C++ development. That coupled with amazing built-in and user developed modules...really makes Python my language of choice when doing ANY development, including processor-intensive stuff.
As long as I program in the proper Python style, I find that my application development time is reduced significantly, the incidence of bugs are very low (less than 1 per 10 lines of code, usually syntax errors - forgot a paren or colon), and maintainability is high.
If you are talking about the Linux Kernel, only recently Linus adopted a version control system (bitkeeper). There are many huge projects maintained on CVS though, and this includes KDE and GNOME. But, the common denominator to all these projects is the fact that the source was made publically available for peer review and international collaboration.
I've found, in the last ten years, that the most detrimental part of the software engineering process are twofold:
1. People with a kneejerk bashing reflex. These are the ones who carry on holy wars, bitching and moaning all the way, when if they would just shut up and do the best with the hand they were dealt, some actual work can get done.
2. People who can't seem to follow the processes established for a project. This is especially problematic for government contacts.
There is neither a perfect set of software engineering tools nor a perfect process for *every* situation. The software enginerr that knows how to effectively deal with the shortcomings of his/her environemnt and can stay focused on the task at hand, rather than bemoaing every little thing is ahead of the game.
When I want a bunch of things in order I stick them into a cursor or other data abstract and say "sort".
My Journal
So, how would you save the compiled code? And, can you optimize it ?
Pain is merely failure leaving the body
Always struck me as a wonderful idea. Fifteen years ago I worked at a place where the client came up with a new idea in the morning and we aimed to demo a solution that afternoon in OO Lisp. A lot of fun, and it made having a dialogue with the end users a million times more useful than Bible-thick specs that no-one can get their head round. Maybe programmers don't actually want clients telling them how they want programs to work?
Virtually serving coffee
In the last 15 years, I've been grateful to improvements in process. Great bug tracking software (I use bugzilla) and source management (cvs) has improved the process of writing and maintaining projects greatly.
In terms of language and library improvements, I think they enable programmers to finish projects much faster than they could before. Well, much more complicated projects. I think that OO languages allow programmers to write good code more easily.
Finally, I think these improvements most help good programmers. Anyone can code poorly, but good programmers are still hard to find. Process is as much a part of programming as language/library knowledge. When I was in school this was not really emphasized, and I think it's an important aspect of coding that most programs still fail to mention.
NAFAIK. (Karma--, but necessary post)
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
I'm too young to say if it improved since brooks published his first book but I can say that the processes around project management improved.
At least in major corporations there is typically a huge intellectual capital (somewhat I hate that word...) involved in project management. Processes, documentation, evaluation.
When brooks wrote his book these weren't as good as they're now and they didn't have the experience.
Although with increased complexity in today's projects and hypes about various technologies and pressure on project managers by senior management I'm not sure if quality really imporved.
IMHO it's not important if quality increased but that we learn from our past mistakes and at least mitigate risks that we've already experienced. This way it can only become better.
The Objective-C language has been around for a while, but kinda got locked-up in proprietary runtime implementations by NeXT (now part of Apple) or the Stepstone corporation which were amongst the first to come up with an Obj-C compiler (for x86). Now, GCC does Obj-C and MetroWerks also has an Obj-C capable compiler. Also, the entire runtime is now open sourced in Darwin, the core OS at the base of Mac OS X, in the form of "Core Foundation" and "Foundation Frameworks".
Couple that with the open-source API SPECs (oppose "implementation"), and you have an amazing combinaison.
On the Mac, this is now known as Cocoa. Cocoa is an object framework that's now mostly accessible via the Java programming language.
For Linux (x86, but soon PPC as well), thetre's AfterStep, an open-source implementation of everything that had made the NeXT a NeXT, including the dev environment.
If you have access to a Mac, get yourself some tutorial and explore Cocoa programming. If you only have access to a Linux box, get yourself a complete install and explore what you can do with this.
No amount of description actually gives any justice to how amazing this dev environment actually is.
If you're tempted to explore further, o'Reiley has a couple of Cocoa books, but the very best Cocoa books out there is written by Skott Anguish and al, and is called Cocoa Programming.
The problem is that the big players priced the Compiler based Common lisp development frameworks right out of the reach of most business developers. They also failed to take full advantage in the increasing capability of the PC, turning their noses up at in favour of past glories of the Symbolics machines. A good Lisp compiler could factor out the "cons", producing code sometimes surpassing the performance of C++.
The void was filled mostly by C++ and now Java, lesser beasts dispite their current quality standard libraries, overly verbose and fragmented incomparison to Common Lisp elegance.
Today there are open implementation of the lisp compilers, but they still lack a comparable development enviroment to the commercial varients. Sadly, since I started professionally in 1988, I have not had one job or contract were they would consider the adoption of Common lisp, and I have never programed professionally in it. David Betz's XLisp, and later XScheme was the closest I came to using it at work for scripting, and at home for some early AI-planning system hacking that has yet to see the light of day.
In my opinion, IBM's Eclipse IDE has finally comming close to surpassing the old benchmark of the commercial Lisp IDEs, it even has the ability to plug in refactoring tools. But then I can remember when, thanks to the "cons"-ed Lisp, manupulating the source of the program was as easy as mainpulating the data,
It's never been about the process; that is simply a crutch to allow bad programmers to become statisfactory ones...
Good code is still written by good programmers.
Software is at best a cottage industry of craftmen that have widely different abilities. At worst, it is a cottery of alchemists that promote their own secret snake oil recipes and only succeed by sheer luck.
And I am a developer that calls himself a software engineer, so this is not a flame.
Why craftmen? Because we develop with tricks and recipes, often called "processes". But neither of these are scientific processes. They cannot predict the outcome of a software project within a definite set of constraints. They cannot be disproved. And they cannot explain failures. So they aren't science, they are rules of thumbs. The guy who makes a living by applying rules of thumbs and learned tricks is a craftmen.
Why alchemists? Because scientists publish their methods and their results. To the contrary, the software industry hides its customer references and does not publish its source code (with the notable exception of Open Source, with remains the exception in large-scale software projects). This is how alchemists and "savants" worked in the Renaissance. They hid their trade secrets, they had confidential relationships with rich patrons, and they feared full disclosure.
On top of that, each subbranch of computing has its own lingo and redefines as many words as possible. Mathematicians who specialize in field theory topology may not understand number theory, but at least, they use distinct, well-defined jargons. In computing, terms like "record", "field", "server", "link" are so overloaded that they are just noise.
About 60% of all software projects are cancelled or written-off as failures. I don't think civil engineering or, say, aeronautics have such a abysmal track record.
I hope that some day, we'll practice and teach Computer Science as, well, a science, not as a craft.
--
Mad science! Robots! Underwear! Cute girls! Full comic online! http://www.girlgeniusonline.com/
...Doesn't work. Ask NASA .
I currently have no clever signature witicism to add here.
After years of debating and haggling with OOP fans (I think OO is way overhyped), I have concluded that an important factor is the personal psychology of the individual. IOW, "mindfit".
People simply perceive things differently and are bothered and helped by different conventions, notations, traditions, etc. Each individual has to find their *own* silver bullet, or at least a brass one. Some of the surveys by Ed Yourdon seem to back this. OOP scored higher when "OO fanatics" worked on projects, but as OO went more mainstream, its score faded into the background noise (average).
Perhaps IT shops can focus more on screening for individuals who think alike rather than simple buzzword matching. It perhaps is time for an inkblot-like test for developers.
I used to complain about how Perl is a "write-only language", but I later realized that it is just write-only to *me*. If other Perl fans can figure out Perl and are productive under it (both in writing and maintenance), then I see little reason to complain. A given shop just has to be willing to accept the fact that they are married to Perl and Perl-loving developers. But if they can get things done, then why should I or anybody else fuss? One man's spehgetti is another's gormet favorite.
(It is still important to explore other viewpoints to expand your horizons, but if something does not seem to "click" for you after a little while, then don't feel bad. I am tired of "you just don't get it, neener neener" from various fans of different paradigms or languages.)
Table-ized A.I.
Not to crash their party but hasn't NASA that crashed their multi-million dollar Mars probe because one sensor took measurements in the metric system while the other was stuck with the imperial one (yuck!) and the software did not convert those? Anybody can tell you that science and the imperial system do not go together... Ain't rocket science ya know...
Or (this are the frecnh now) hasn't the Ariane rocket crashed because of a integer overflow in a software component "inherited" from a previous rocket that could not have produced such a value and therefore was not checked...
So there you have it.
Please come back when you know what you're talking about. Until then, HAND.
Canada's National Software Engineering Conference might try to answer these questions for you. If you are a university student or in academia you should check out:
http://www.cusec.ca
If you do a formal design using elements like Z you can test that the design works. You can also do this using things like OCL to define the requirements/pre/post for the classes in your design and then running conditions against this.
There aren't many products that do this yet as most people don't see the need, because most people don't test code properly, let alone designs.
An Eye for an Eye will make the whole world blind - Gandhi
I agree. Unfortunate, but true.
Management says problems with slow code can be solved by buying faster machines. Because after all, these days computing power is cheaper than human power. There is almost no incentive when whatever you produce is "good enough".
Let's be honest here. If you have a 2.4GHz machine, you might not care or know that your code might run slowly on someone else's lesser machine.
Just as the hardware industry has grown from abstracting commonly used circuits into chips, what occurs is the creation of building blocks on standard designs. In the software sector, that would equate to a component architecture which keeps building on what's been done in the past. The big problem here is that if ANYBODY starts trying to hide anything in Microsoft Windows, Microsoft eliminates them from the market. C++ frameworks were very popular in the early 90's but they all but disappeared as Microsoft provided their C-- (object like) way of doing things at a financial loss. Borland was a leader in the C++ dev tool market but their work hide MS Windows API's so much you could start building applications that recompiled on many different operating systems. MS gutted Borland of it's top level design engineers and paid Borland a tiny fee to settle out of court. CORBA was another framework for building applications across a network of different operating systems and languages. We got 3+ years of intense MS-DCOM press coverage and CORBA eventually faded. I worked on a project which was to use CORBA for a large military hospital system but 1 year into it we were told to stop and start using MS tools and languages with no explainations. Java did/does the same thing( OS/API abstraction ) and it too was fought by Microsoft with incredible gusto.
As long as Microsoft holds the major share of the desktop computing platform, they will not allow anybody else to decide what's to become a standard software component or API. And changing this every 2 years or so keeps the $$ flowing from your pockets into theirs.
Sure you can do some of this within your own organization but as an industry, the largest software company in the world opposes such thinking. And with $30 billion in cash, they have the power to change the minds and directions of whole countries.
IMHO
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
[flaw in a given function at one point is always followed by exasperation because one realizes that the function needs to be changed in X number of programs.] You don't need a new version control tool, you need a refactoring tool.
Sometimes a change in *interface* will ripple throughout a system. This is hard to avoid. WRT functions, named parameters often help IMO. You can add a new named parameter for those callers (users) which need the new functionality, but those which don't simply don't use that named parameter (and it defaults to something inside the function/module). Languages without named parameters seem to have more problems with parameter count changes.
Table-ized A.I.
So maybe XP should be viewed as expensive but useful 'grease' to use where necessary.
loss of performance with the current obsession on over-inheritence and Java-style interpreted/P-code software overall.
Most companies see the small performance loss from using object oriented languages does not compare to the loss in man hours maintaining non-OOP code. OOP code scales better when that small application gets larger. Code reuse is simpler and can aid in quicker development of other applications with similiar functionality in the future.
The "vanilla unix" does not exist anymore so its not really an issue. The original idea of byte-code compatiblity was lost when unix commercialized. This spurred the development of a language like Java which allows code to be cross-platform. Writing in ANSI C would be another way of doing this if only it was implemented the same across the Unixes and the hardware remained a constant. That will never happen.
Add to this GPL/OS that slashes meaningful business value from well engineered software components
I think that there are many well engineered software components under the GPL and could give plenty of examples. These components required the experience and time of many programmers. By sharing this codebase IT departments do not have to hire dozens of programmers to create a similiar product.
You may be a "professional" developer, but I think you should avoid any position where you would have decisions on the direction of what technology is used within your company until you come into the realization of the economic savings of GPL code and the reasoning behind object oriented languages. These subjects are generally covered in most computer science programs at most universitys.
...and I'm surprised no one mentions it too often. Things like generative programming, aspect oriented programming, domain engineering, the list goes on. They are all headed towards filling in the gaps where OOA/D falls short (and yes, it DOES fall short. WAY short) and creating flexible, general programs that are highly reusable and highly correct with a minimum of change. It's really great stuff, straight out of Star Trek. And if you think it's just theory, it's not. Do some research and find out that big (and I mean BIG) companies are going this way.
I'm perpetually amused at those seekers after a silver bullet.
Their faith in the existence of a magic method is comic.
All of these studies roll up statistics for us to nod at knowingly, yet they are impotent when it comes to taking creativity and serving it up so that the novice can be productive. That bit of Southern engineering wisdom: "y'all just cain't polish a turd" applies to staff as well as designs.
People just don't aggregate, and pursuit of models and methodologies is a diminshing-returns game. Have a model. Have a methodology. Stick to it. But never mistake this means for an end unto itself.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
The focus has definitely shifted away from algorithms and toward abstraction.
The term "abstraction" is another overused, overabused, and now watered-down buzzword, I am afraid to say.
It generally means, "Hiding away stuff that you don't want to worry about", but has taken on all kinds of paradigm- and language-specific meanings to suit the author's POV.
A "fun" debate tactict is to call anything you don't like a "low level detail". This will usually result in a fat flamewar along the lines of "my thing is a *higher* level than yours, neener neener....".
I would also note that abstraction is relative. The proper abstraction for one user or module may not be sufficient for another. An accountant and an engineer may look at the very same parts, but each will have (or want) a very different view. Techniques that use "levels" (hierarchies) of abstraction tend not to do well with such relativism. Point of views are needed, not levels.
Levels are like a map zoom-in/zoom-out. However, perspectives are like a geology map versus a road map. Zooming is an orthogonal issue to what the map actually shows. Also, in some cases one may want *both* views on the same map so that they can take the right road to find the minerals they are seeking.
Table-ized A.I.
However, take a look at Parnas' classic paper on information hiding. In it, he makes the following statement (emphasis mine):
Is there anyone in the crowd that doesn't think he could write a shell script/perl script/etc. to accomplish this in 30 minutes or less? I'd be willing to bet I could do it in Python in under 15 minutes.This paper was written 30 years ago. It only pre-dated Brooks by 5 years. In that time, if my estimate is accurate, the development time for simple programs may have fallen by a factor of a hundred or more.
Software doesn't appear to have improved in that time simply because we keep trying to do more complex things.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
All the developments in tools described by the questioner have bought improvements in both speed and quality of programming. But they are small increments - 10% here, 50% there. Structured programming was an advance on spaghetti coding, and OOP an advance again. But while software productivity has, maybe, doubled or trebled, the size of the problem has tracked hardware with Moore's law. The result is that software developers are *always* on the back foor. And I agree with Brooks - there is no silver bullet. We will always be on the back foot. But new tools will help a little.
Actuall, for all the spiel about different languages, styles and tools, I think the biggest advances have been the intrioduction of portable, well tested, well documented libraries. The best tools in the world don't beat pulling 90% of the solution out off a hat.
Consciousness is an illusion caused by an excess of self consciousness.
"No Silver Bullet..." was written in 1987. By *my* math that's only about 15 years ago.
His book "The Mythical Man-Month" was written in 1975 - that's closer to 25 years.
I assume the poster of this item is confused since the "No Silver Bullet..." article was included in the 25th anniversary edition of "The Mythical Man-Month" - released in 2000.
The problem is that the big players priced the Compiler based Common lisp development frameworks [which have MS-Visual-Studio-like editing and auto-complete features] right out of the reach of most business developers. They also failed to take full advantage in the increasing capability of the PC
:-)
Well, Microsoft maybe invented a new technique: start out charging (relatively) low and get your revenue by locking people into your proprietary stuff rather than frisk them up front.
I don't know of any IT company that did this before Microsoft. I don't remember that complaint logded against IBM in its monopoly heyday (I did some reports on IBM complaints in school), but I could be wrong.
The best innovations of the last 20 years are perhaps marketing innovations
Table-ized A.I.
I have an idea -- why don't you choose your career wholly on the basis of whether there are lots of jobs available in that career at the time you are in college? Then when the economy, and the entire world, changes in 10 years, you'll be God knows where. Not to mention the fact that what you've chosen to do with your life will have absolutely nothing to do with what fulfills you or what kind of person you want to be, and you can spend 40 hours a week miserable because you really don't like X at all. Sounds like a great plan! Just remember: money is the only thing that matters, and that when you are lying on your deathbed you definitely won't be looking back and asking yourself what you did with your life!
May I point out that programming languages can be used to develop things other that software (although related) nowadays.
Probably, the thing I find most interesting is hardware, which can be described using Verilog or VHDL, both Hardware Description Languages. That, together with technologies like FPGA, enables a programmer to design his own microprocessor if he wishes to do so, I find that revolutionary.
Tools have given us incredible power over just about any language - C/C++, Perl, Java, etc. But does the average programer really understand what they're creating?
I've tried several IDEs for Java and Perl, and still end up back at my basic text editor (EditPadPro). Why? Because those IDEs tend to throw so much extra crap in my code, and I don't even know what that code is doing half the time! I don't know how many times I've seen programs that have every possible bell-and-whistle thrown in, but if I have a question about the code (why is this routine trying to connect to another computer?), the IDE author isn't sure. "Well, I just dragged it onto the tree, and there it was!".
The same can be said for most WYSIWYG HTML editors. I prefer using Dreamweaver, simply because I can easily look at the code I'm creating. But I am always leary to suggest Dreamweaver to someone with no HTML experience - where we have, we've ended up with 500k web pages with crap bouncing all over the screen.
Tool or no tool, there's no substitue for experience and knowledge.
"The large print giveth, and the small print taketh away" -- "Step Right Up", Tom Waits
The best way to ensure the project you work on is successful is to pay attention to the business side and learn how to work with business people effectively. Without that, it doesn't matter if you use XP, OOP or whatever you choose.
1) Hotspot: definitely interprets TODAY. Designed to interpret. Just intelligently compiles the most-commonly used code. And yes, it's a major speed boost to do things this way. But tight C/C++ would be faster. Roughly, all Java ~ mediocre C++, which means it's easier to write good Java, but Java won't solve all problems.
2) Trying to compile everything (bytecode->native) beforehand is what makes the JVM so slow. A programming language that loads 40Megs of memory for a GUI and takes several seconds to load (on a fast machine!) is bad. And then you close the program, and lose all the gains running it and compiling efficiently earned you...
A witty [sig] proves nothing. --Voltaire
OCAML is a very practical functional programming language with excellent compilers. A number of Linux utilities are written in it.
Syntax is entirely a matter of opinion, and anyone who gets hung up on it is being shallow; (or can't figure out how to write a pre-processor...) this was the one thing that completely baffled me in the old C/Pascal debates. Even at the time, there were translators available to convert Pascal to C, and they did an ok job, so quibbling about the syntax (and not the language features) seemed completely useless and absurd to me...
pb Reply or e-mail; don't vaguely moderate.
Well, you are assuming that he is a smart person.
Your other comments also seem to assume that there isn't a sea change taking place. That sea change is globalism and the strength of the American dollar pushing companies to outsource to every Third World country they can find.
I would recommend to ANYONE still in college to steer clear of CS and engineering, too. I'd say go for something where you will have some kind of dignity. Maybe doctor or lawyer.
Even during the boom years, there was very little dignity given to CS folks. It was done only very begrudgingly, and if "dignity" only means high salaries (with looooong hours) and giving people Nerf guns but still putting them in cubes, then my definition of dignity is way off.
For the past 2 or so years of the down market (job market didn't *really* start sliding everywhere until late 2000, even though stock market took a serious dip in beginning of 2000), I was treated like a slave - I had SALES guys "managing" me, telling me that they could replace me tomorrow, etc. etc., and that's only when I was working. I have been out of work 6+ months in those 2+ years.
I don't remember doctors or lawyers ever being run out of their chosen field. It seems to happen a lot in engineering and CS.
As for some folks who said that CS degree will give you that edge - well, out of the hundreds of resumes some of these jobs are getting, I guess I will be in the "top" portion of these - but I have no idea what that percentage is. Even if it's only 10%, that still puts me in with 30, 40, 50 other people competing for the same job. If you like those odds, go for it.
Just realized what I just said. Java is better the longer the program runs? Very, very strange... /shudder/. Meaning, Java is exactly the WRONG thing to use for an applet and the RIGHT thing to use for a heavyweight editor!
A witty [sig] proves nothing. --Voltaire
>The difference between contracting out to an Indian IT farm and hiring a great programmer -- from any country -- is rather akin to the difference between employing 100 monkeys and hoping one of them will bang out Hamlet, and hiring William Shakespeare.
I find the racisim implicit that statement quite staggering!
So, Indian programmers are '100 monkeys' and programmers from the good ol' USA are 'William Shakespeare', right?
Actually "No Silver Bullet: Essence and Accidents in Software Engineering" was published as an article in Computer magazine in April 1987. That was (for the math challenged) only 15 years ago, rather than 25 years ago. I remember reading the article in its original form in college and I don't think that I'm THAT close to retirement yet...
Racist accusations aside, the analogy is quite good.
All too often, the results from offshore programmers are very close to the "100 monkeys" he spoke of.
Nothing fundamental will change because of the Law of Uniform Pain. At any time when we can create function x for software pain level n, improvements will improve the relation of x and n. But instead of preferring function x and pain level n-k, people will instead choose function x+k and pain level n. (Of course, the change might be in exponents, but the margin is too crude to contain it...) And so it will feel the same, although the software generated will be more powerful/functional/etc. I believe this was originated by an academic named Erbach.
I think people like Brooks have done a grave disservice to the community by claiming, without solid evidence, that languages don't matter. Some language differences don't matter--Pascal and C are almost equally cumbersome and error prone. But in general, languages do matter enormously: runtime safety makes it easier to compose programs out of large numbers of components, dynamic typing and reflection help with configurability and I/O, static type safety and garbage collection reduce the probability of bugs, etc.
A disregard for the importance of languages is why projects like Mozilla, Gnome, and KDE keep lumbering on in languages like C and C++, producing software that crashes with regularity, consumes enormous amounts of memory, and takes forever to get finished. It's why software like Apache, IIE, and IIS keep shipping with bogus and avoidable buffer overflow errors.
Programming technology has improved enormously over the last three decades. It's just that most programmers don't use the improvements and still stick with three decade old technology for their jobs.
There are some really amazing things going on... and I'm surprised no one mentions it too often. Things like generative programming, aspect oriented programming, domain engineering, the list goes on.
I'm interested in hearing more... do you have links to specific pages that exemplify some of these practices?
Code completion/syntax checking has probably saved me countless compile/debug cycles.
n ance 1->reengineering->maintanence 2.
I think the only way to become a better programmer is to suffer through a product's first few life cycles: concept->analysis->design->implementation->mainte
After the second maintenance cycle you're just milking the cow, so move on to another start-up project and apply your new-found experience elsewhere.
The point is, until you have to maintain and rewrite you're own mistakes, you don't learn much of anything.
Up until the recent past, unfortunately, a lot of startups have been bottom-heavy with young, inexperienced developers who are willing to put in the long hours necessary to brute-force their mistakes through by whatever bandaids and chewing gum it takes. That's a hit-or-miss proposition.
Alas, it's very hard to get a doomed project cancelled or realigned due to political inertia. When it becomes obvious that management is living in Cloud Cuckooland, it's time for you to pick up sticks and move on.
If you post it, they will read.
what bugs me about java is its verbosity. just to open a socket and write to it is like 6 or seven lines. perl is one line. i am sure there is a happy medium. (no, i don't know enough c to compare). also, java bugs me in that there is only one way, as opposed to the perl's there is infinite ways. again, a happy medium thing. what i have found though is java can do basically anything, and it is relatively easy to learn. perl on the other hand can do anything, but is a bitch to learn. but other than that, i have been very productive with each. in fact, i just fire up vim and have a tererminal or two open. i have tried every ide, and like none. except for jedit. really nice and fast, for a java app.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
Hmmm,
.NET era engineers of what "Managed C++" is and so I'm currently coding an unnecessary Managed to UnManaged code layer so that C# can talk to unmanaged C++ on the back end...
Of people and projects and the use of tools and technologies:
Let's see... Two contracts ago I was on a team of developers who had one hammer in their toolbox: COM. I pleaded with them to limit their use of COM but they went on a rampage. They wrapped ADO in a COM based object/relational DB abstraction. Then they used the COM based DB wrapper in their COM based business tier to talk to COM based Active-X controls in the UI. I pleaded with them to use MTS, distributed transactions, and stored procedures as the system was a distributed client/server app; but I was told that transactions and stored procedures would add too much overhead. COM, COM everywhere and no transactions in sight! Result: A slow, giant, buggy, leaky, unstable 4 tier COM based pig of a system that has major database issues. I finally couldn't take it anymore and so I gave notice after 1.5 years on the project. I left there 2 years ago and today they have sold the thing to one customer - who is extremely unhappy...
My last contract was an aircraft carrier combat system. 220 developers had been playing in Rational Rose for 1.5+ years when I showed up. They had modelled over 5,000 classes and had not modelled anything called "Weapon", "Sensor" or "theShip". They used Rose to generate their C++ code for HPUX and VxWorks and they used TCL/TK to do their UI. Frankly, if there a was a fork in the road these guys took the hard way every time. Result: the system is an impossibly huge nightmare that runs on dying platforms and depends on a dead UI language. The company has run out of money to finish the system. The staff has been cut from 220 to 50 and no deadlines have been moved. None of my friends who remain on this project work 40 hour weeks...
Currently I'm on contract to do a UI by X-Mas. I just fought a 2 week pitched battle with pig headed engineers over whether or not we should use C#, VB, or MFC to do the UI. I finally ended the battle last week when I walked into a meeting with working screens coded in C#. The UI is mostly finished and all are very impressed with my work. But I have been unable to convince unwilling, MFC loving, pre
I guess what I'm saying is that the biggest thing I've run into in the last few years is people who have very real design decision making power but who don't have a good background in what tools and technologies are available. I see projects blunder into Death March situations because the people working on them are unwilling to keep up with technology or are unaware of what tools are out there...
I work like heck to keep up with the times. I wish more people would read books like "The Pragmatic Programmer" and take them to heart...
--Richard
No one can claim that a program written in Java is as fast as a program written in vanilla c. For that matter, when real execution speed is required, people still optimise in assembler (or even design custom hardware). Java is not designed for execution speed. No point in pretending it is. Different lanuguages are useful in different situations. They are tools. There is no point in claiming your screwdriver is better than my hammer. Java is slower than c. So yaaahhh
Silver bullets do exist! They have to! Otherwise, how will we kill all the werewolves?! (or get drunk!)
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
Well, tight C++ code may be a confusion in terms given its prepenstiy to leak memory.
another day, another line of code, I'll debug it tomorrow.
Why would you want to scroll? Why not use it for real programming?
Lets not confuse Java the language and its performance with Java GUI framework. Just like you would not compare C++ the language with the Microsoft windows framework.
The Java framework sacrifices some speed for generality. So see what you save writing it once and delivering it to multiple platforms vs re-writting the GUI portion for another platform. There is method and cost to this madness.
Java can never be as fast as C or C++. I don't know what 'your benchmarks' are, but have you published them? I think you are outright lying if you have ever been able to get Java to perform faster than any native binary in a sufficiently _fair_ test. It defies logic. Every Java 'instruction' in the bytecode translates to tens if not hundreds of actual machine instructions. Its slow and bloated.
There are, however, skewed tests which make Java look faster by making the C++ code used in the test do things the "dumb way" by passing around a lot of object copies rather than references.. this type of thing makes Java look almost as fast as C++ _on a very limited subset of problems_ (even with all the object coping). Java programmers claim this is a fair test because everything except (for the most basic types) is a reference in Java. The Java pundits like to point this out and say "yeah Java is faster because all objects are references". This can be true if you are a dumb C++ programmer with no sense of efficiency.. but just a little extra effort can get you as a programmer to think in terms of what is more efficient and use references when you can and thus you leave Java in the dust. Native binaries are several orders of magnitude faster than Java's interpreted bytecode. It's a pure fact. Anything else is FUD.
The tools make probably 10% of the process easier. The ability to cut and paste text is the biggest gain from tools, with every other tool declining in return for investment. Fundamental to tools is the fact that every time a tool comes out to fix a certain problem, we increase the magnitude of the problem until the tool is ineffective. Secondly, tools don't give you a competitive advantage because everyone has the same tools. The human brain and the ability of the people is still the only thing making a difference.
Well he's either a troll or a Karma whore. He makes a retarded argument. Basically you are correct. In java you can either ignore the exception and get a reasonable error message with zero effort from you.. or you can have a big try statement wherever you want to and catch (OutOfMemoryException e).
The alternative in C is ugly. A million if() statements for every malloc that basically do the explicit checking. Big whoop.
Actually the java approach is superior in the sense that at least the vm tells you "Out of memory" with zero work from you as a programmer. With C you have the extra "printf("Out of memory\n"); exit(ENOMEM);" code after every malloc. In fact the Exceptional approach to memory is way better IMHO.
Yeah, Delphi and Kylix really don't get enough mention. It amazes me how little they are mentioned on Slashdot. Delphi is still the best development tool that I've used. I've used C++, Delphi, Java and VB and x86 assembler. Delphi is the only language / tool that I've used that really is able to handle the full development spectrum. It is almost the one-size-fits-all development tool. I say "almost" because it you can't write apps for Solaris or MacOS. But, the reality of it is that you can write apps that are just as scaleable on Windows or Linux using Delphi, so there is no real need to develop on Solaris.
Refactoring will solve exactly this problem, one of the refactorings (Rename Method) allows you to change a method and have the method calls be changed to reflect this. Refactoring like these are extremely handy and are one important way to solve the problem of reducing and managing duplicated functionality (AspectJ is another interesting solution).
The Drowned and the Saved - Primo Levi
Incidentally I've read several things that talk about the fact that Hotspot server version is the one everyone should be using....even if on the client. Client is only designed for short-lived things like applets.
My blog: http://jkratz.dyndns.org/~jason/blog/
That one sentance, which was Brooks' key insight, sums up why progress will always be limited. You can read commentary on that point in a paper I wrote here.
Other's have already pointed out the obvious corollary: good management practices are most important for successful, reliable software development.
I don't think the Agile people need to be trashed as much as they are here. Sure, they are gurus. But they are emphasizing human-centric instead of "software engineering" which is a Good Thing (TM). Just don't get too religious about XP and you'll be fine.
Other than that, the greatest thing for programmers since sliced bread is Python.
And yes, I also agree open source development has pushed this industry light years ahead. But it works because - it's human-centric programming!
As to 2 I don't know of any Java application that I've used yet that takes 40MB of memory on load. I agree though that you do lose the gains made on loading/compiling to native. Sun needs to address that issue. OTOH you can also buy native compilers that do the work upfront. If you want a fast GUI use SWT. Not as functional as Swing imho but certainly faster.
My blog: http://jkratz.dyndns.org/~jason/blog/
There are plenty of Common Lisp tools (IDEs, web servers, utilities, etc.) available at reasonable prices or free: Allegro Common Lisp, Corman Lisp, CLISP is free...
Go read the Lisp Tools
Everything you need is available. Get a Lisp today!
Until one comes up with a meaningful version of each version coded properly to use the strengths of the language in question you can't say that. Server-side Java is extremely fast and you gain far more coding in Java on the server than you'd lose in speed.
c. For that matter, when real execution speed is required, people still optimise in assembler (or even design custom hardware).
Uh...whatever. People who worry about that type of optimization wouldn't be looking at much more than C or C++. Java and the like aren't even on their radar.
Java is not designed for execution speed. No point in pretending it is. Nobody ever claimed it was.
Java is slower than c. First off its C....not c. Secondly you can't make that claim. It certainly is true in some respects and not so in others. Making that claim is pretty much pointless.
My blog: http://jkratz.dyndns.org/~jason/blog/
Just to clear something up from the posters comment, the Unified Modeling Language is a notation not a process. Period. End of discusion. If you want a process that uses the UML look into the Rational Unified Process (RUP), Unified Process (UP), or OPEN.
Why the hell would you be wasting your time even acknowledging a salesman. Not too mention letting one try to "manage" you. allowing such a thing demonstrates a total lack of confidence and assetiveness which adversely impacts ones employment in tough times. When the axe falls, the weak get cut off. You can be the best IT worker int eh world, in a corporation, you still have to demonstrate the traits which a corporation finds desirable in all workers.
Refactoring will solve exactly this problem, one of the refactorings (Rename Method) allows you to change a method and have the method calls be changed to reflect this.
Are you saying this is better than named parameters, or just of many techniques to consider?
Table-ized A.I.
Have you actually red more then his latest assignment?
His resume goes back to 1974! I was 6 years old and had still 7 years to go to get my hands touching a computer myself.
Just one example, 1979: "Debugged and enhanced software for the Space Shuttle flight simulators at NASA/JSC."
It half of that resume is truthful, other developers (including myself) would
kill for it.
Twenty years ago, methodologists described the software crisis as the difficulty in building reliable but complex software systems. I truly believe that a lot of the "best practices" established over years have improved our ability to build good software.
But the real software crisis we face today is that most software we use never underwent legitimate requirements analysis. There was a time when large organizations sought out software solutions and paid to have them built. The vast majority of software used today in business, was not build against user requirements. Instead they are built to meet buyer requirements or marketing requirements.
Mass-market software (ie. everything that runs on a Windows PC) isn't built at the request of its user. Instead, companies built software based on what they *think* users want and then close the gap by marketing their pre-built products to us. Users have very little input into how their purchased software will function. Often a software company will spend a disproportionate amount of money adding features that will attract buyers not users.
I mean think about it: The core functionality of word processing software has remained unchanged since the days of Magic Window and StarWriter. There is only a finite amount of functions a word processor can perform.
There is, however, an unlimited number of features a company can add to a product (functional or not) in order to distinguish it from a competitor or previous version.
The vast majority of software is not purchased based on satisfying a clear set of requirements. We buy MS Office because, well... just because.
That's the real software crisis.
First learn the language of the sages. Warp your mind around its concepts. Get good. Then give it up and go back to one of your other more enjoyable languages.
I disagree somewhat. Good practices can make a sub-standard team into a gets-it-done-well-enough team, or a good team into a great team. They won't turn a lousy team into a great team, but you'll never have a great team with them, either.
I disagree with that as well. There are plenty of good developers out there. The problem is invariably that management fails to acknowledge the nature of good developers, usually in one of two big ways.
If management could get over its short-termism and help good developers to develop well, then they'd find that such people really aren't that rare at all. There are a few in every company I've ever worked at, and I've worked on some teams that consisted almost entirely of high calibre people. But just having a team of good guys isn't enough; this is why good management is worth what you pay for it. Kinda like good developers, when you think about it... :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I use jEdit (4.0.3) for my coding also, but it really is quite slow. The menus, the response times, the dialogs, the loading, everything seems to be stuck in a slower dimension. I have the J2SE 1.4.1_01, too. Any advice?
By the way, my computer's faster than yours.
WeRelate.org - wiki-based genealogy
I can't help feeling that this post is off the mark.
The issue isn't software complexity, it's how well the software does its job, which is helping real people to do something more easily.
Yes, it's true that one drive individual used to be able to write full packages. Of course, that's still true. Many of the best tools I use look every bit as professional as the mass-developed, highly-complex things, and work at least as well, yet were developed by a single enthusiastic person. They have a smaller scope, but on the flip side, they tend to do their one job very well.
As for collapsing into mayhem... You are more generous about current software than I am. When did MS-DOS or WordPerfect 5.1 ever crash and lose your last hour's work? Yes, yes, they weren't multitaskingGUIfrontendmousewavingbizapps(TM), but they let me write my letters, booted in a heartbeat and didn't keep asking me if I wanted fries^H^H^H^H^Hhelp with that. I accept that today's software tries to do much more, but it's hardly an exemplary field for progress in an engineering discipline.
Oh, and WinXP is so much less stable than Win2K it's not funny. I speak from direct personal experience, on several different machines at several different places. Win2K was the one MS got right. WinXP was the candy-covering they forgot to taste before they put it in the shop.
Having said all of this, I do think software development has advanced a lot as a field. I just don't think your argument justifies that conclusion in itself.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Unlike any other theories, software engineering theories are just unprovable principles. Among all the different languages, methodologies, people are choosing. More interoperability between languages, better revision control system, better distribution system, better bug reporting system, more specific coding guidelines... Slowly, things are getting better and better, when people started to know what exactly they want (not just some hollow words).
Sure. I'll also recommend some books which are on the cutting edge of what's going on in these areas. By far the definitive guide is "Generative Programming" by Czarnecki and Eisenecker. They delve into Domain Engineering, Aspect Oriented Programming, Intentional Programming (being developed by Simonyi @ MS), and other topics in general programming. The book is great, and you can check out Czarnecki's website associated with it which includes source code and links to other online resources. Other literature currently close to my heart is "Modern C++ Design" by Alexandrescu, which deals with Policy Based library design (closely related to the idea of generative programming; it allows C++ to act as a 2-tiered language by giving the compiler the ability to make decisions on what should be compiled), and anything that you can find on the Eiffel programming language (I suggest The Official Eiffel Software Homepage) which implements Design by Contract (DBC). Basically this states that there are certain pre- and post- conditions which must be met by each part of your program and places constraints on the code based on the 'contracts'. As a side note, this can currently be spoofed in C++ by using the static assertion library. Wow, that was long-winded. In any case, hope that helps. If you want more info, drop another post.
FWIW: I believe that if you have programs that are going to be running for a good long while, the Java 1.4 VM -server option will optimize heavily-used code. I don't have my 4th-ed Java in a Nutshell handy, which is where I believe I read this.
As for Java performance, I think the best piece I have seen on it so far was a few months ago in Java Developer's Journal - The issue's archives page lists it as "Performance Tuning in Java" - but unfortunately you need to be a subscriber to access the archives, and I am not. There are of course a lot of steps you can take to make Java *relatively* fast, but I think prior posts covered most of those.
I don't know well LISP stands up in a production environment -- in that I have no idea how easy it is (or is not) to read and understand and maintain someone else's LISP code -- but just for the perspective and the opportunity to get a revelation, I'd advise giving LISP a serious shot.
Design by Contract and BON (Business Object Notation) provide a very nice agile development methodology. Take a look at Eiffel.com for details.
There are not silver bullets in software development. Probably never will be. So get that out of your mind.
On the other hand, our toolbox is filling up with lots of nice silver hammers, silver screwdrivers and silver saws.
When I started coding, structured programming was the latest tool in the toolbox. It was and still is a great tool for many tasks. Since then we've gotten object oriented and generic programming tools. These are great tools as well. But they're still tools. Which means you have to but some labor into using them, and they won't be suitable for every task.
If you don't think that software development has improved in the past twenty five years, it's time you rummaged through your toolbox and picked something other than a screwdriver to hammer in nails.
A Government Is a Body of People, Usually Notably Ungoverned
I use recursive grep to identify where I call a certain function. I get a few false positives, but usually, it's not too bad.
Stop the brainwash
It seriously takes 3-4 seconds for an "open file" dialog box to come up (Solaris runtime). The second time it's down to maybe 1/3 of a second (thank you hotspot!), and I'd bet I could take that time out by caching the dialog instead of making a new one each time. It's that first pass being way too slow though...
Hotspot in of itself is pretty good. A year and a half ago, I was cursing Java for slow everything - now it's just the startup time and memory footprint - the rest of the language has shaped up nicely. Another year of improvements and I just might switch... :-)
Never gotten to play with one of those native compilers :-(. But I'd bet a good one would take out half my complaints right now! However, I just don't feel the memory footprint is likely to go down.
Hotspot server is better? Very interesting... Thanks for the info!
A witty [sig] proves nothing. --Voltaire
Heh. Non-intuitive, ain't it?
The fact is that C++, in particular, has 'features' that prevent certain optimizations. Java, due to stricter specification, has some advantages. Whether or not Java will ever be faster than optimized FORTRAN is a different question, but largely moot since very little non-scientific software is developed in FORTRAN (or hand optimized assembly, the other performance poster boy).
Anyway, I'm working on a magazine article regarding my benchmarks so I can't release them yet. However, for a much earlier article that shows great results with last generation VMs, check out Binaries vs. Bytecodes. The 1.4 VMs are substantially faster than the 1.3 versions he used in that article, while the C++ compilers have made little or no progress in the same time period. Cool, eh? ;-)
Source is provided with that article, so you can test it with current compilers and VMs.
So, anyhow, before you do any more spouting about "several orders of magnitude faster than Java" you'd better run your own benchmarks. You're in for a surprise.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
I've been programming for 30 years. In that time we've made huge progress with languages, libraries, code resues, etc. However, the growth in the expectations of users and the complexity of the tasks to be accomplished exceeds our progress in improving programming productivity.
Everyone want "easier to use". Making a complex app eay to use is reall hard. And eas to use for whom? Ask 50 users and you'll get 100 opinions on what is easy. And people want to sit down and use complex systems with classes and training. So we add context sensitive help, wizads, but we also need the expert mode.
Then we have the apps that need to be distributed, network aware, fault tolerant, scale to tens of thousands of users, etc. This stuff adds a tremendous amount of cmplexity to design, development and QA. And our requirements are growing not shrinking.
Then, we can't throw out any of the old systems, so we're writing glue layers and translators and front ends, etc. And then those take on a lfe of theri won.
Finally, we need bigger teams. Once the teams get large, the management becomes difficult. That hasn't changed in 30 years. We have new methodology from SEI or others, but it requires incredible discipline and a senior management who doesn't change the plan, cut the budget and lay off 20% of the developers.
I actually saw a listing last week for a software beta testor in Albany, NY. This software company was only paying $10/hr, and you needed to have a BS in computer science.
Ridiculous.
For the last 20 years the commercial software development
:-) deadlines) -- and in fact, we got accustomed to it:
churned through imperative programming languages that do the same thing with just a bit different syntax and Spartan/or complete set of standard libraries (Cobol, fortran, C++, pascal, java, C++, C, perl, C#). So we have wasted investors money,
customers money, many man hours by lying to them that when we use the new programming languages things going to be much better (that self-satisfying process is now called 'commercial software industry').
In addition to manual conversion to different lang. syntax (and fixing some bugs on the way) of the existing software, we spent millions of dollars on what we call 'Design Tools' and those are mere lego-like packages that allow us to break-down our tasks into such small and disjoint components that a developer who was not part of the 'team-that-did-the-breakdown' would need to spend weeks to find out what set of 'components' (an important word in our vocabulary) enables that button (and it turns out that the a row in a database is read by the 'database layer', then the there is code that the checks if that row is has all the necessary data, then it sets some boolean flag (we call that a business logic layer), then the button checks that flag and to be enabled or disabled (and that we called our GUI layer)).
In the last 10-15 years, we came up with a role of a 'Software Architect' -- that probably had a noble goal, but really degenerated into a task of dowloading the latest 'new' technology from the internet, then setting them up for some irrelevant test, and then running around the company and telling everyone how we should 'upgrade to the latest technology for some great benefit and no one can understand'.
Then, in the past 20 years we convinced our customers that they cannot really expect bug-free software from us, but instead we can do something that does most of what they want and fix the rest later. So then the customers simply stopped believing us that we can manufacture something that works, the only thing that customers can do is to request us to do something by some date (therefore the unreasonable (but always movable
Look at the press releases of the public software companies: they do not mention what functionality their products have, how fault-tolerant they are... instead they mention what Tools they used to build their stuff (XML, EJB, Java, OO, UML, web-enabled and wireless ready). And for a while the stock market rewarded just that. But have you seen a profitable hardware design and manufacturing company bragging in their press releases what compiler or VLSI design tool they use, instead of highlighting the functionality of their product?
-----------
We also convinced ourselves that there are no 'methods' to desing software without bugs, instead we'd rather rely on QA to test it -- because we think software is like nothing else -- it cannot be VERIFIED for CORRECTNESS by us.
And that is fundamentally what needs to be changed: we must be able to use mathematically sound algorithm verification techniques and we should ask our tool vendors NOT to deliver to us a syntax change every 3 years, but build for us tools that would do what do data-flow analysis on the program logic level, that would simulate timings and parallel execution for concurrency enabled applications (threading/etc) and so on.
-----
Of course there has been a lot of progress in the computer science and mathematics that supports it, but most of it did not make in to commercial app development world.
Compilers are better, language parsers are better, OSses are better -- but those are the tools where the science was used to design algorithms (like graph coloring for register allocations, or other optimization techniques)
And hardware, of course is much better --
the commercial software 'looks' like made leaps and bounds -- but it is really some of tools that we use underneath that made us look better.
That's not including the 14100 lines of C++ in the main support tool (which won't be shipped) or the other tools, or data.
So short small projects let you be a lot more productive in terms of LOC :-), well until we get into the proper testing phase anyway :-(
My karma is excellent, so I guess I must be a troll.
you can have a big try statement wherever you want to and catch (OutOfMemoryException e)Well, it's an Error, not an Exception. This means that a reasonable application should not try to catch it, according to the documentation. If you go against the documentation and decide to attempt some local recovery after certain failed allocations, you need a try-catch clause around each one.
The alternative in C is ugly. A million if() statements for every malloc that basically do the explicit checking. Big whoop.To be fair, it's at most one if statement for every malloc.
With C you have the extra "printf("Out of memory\n"); exit(ENOMEM);" code after every malloc.Nonsense. If it's acceptable to terminate in the event of any malloc failing, you'd write a wrapper to hide the details. There would be no explicit error checking at all at the call site. Now whose argument is retarded?
Named parameters are nice as well, this is an alternative which has its advantages and disadvantages. If I had to choose I would go for the refactoring(s). They are more versatile, encourage improving your code and save some find/replace (well, a lot actually).
I consider refactoring one of major new OO coding techniques of this decennium (some things might work with procedural programming, but a lot of refactorings are OO specific). If you want to learn more, you should read Ward Cunninghams famous wiki and check out refactoring.com (although it's a bit hard to navigate).
The Drowned and the Saved - Primo Levi
Do you mean Hungarian notation (which sucks in my opinion).
http://www.dreamsongs.com/ObjectsHaveFailedNarr
There is actually a .net ML compiler out there. I just attended a talk by Nick Benton last week and it was really appealing. Take a look at
http://www.cl.cam.ac.uk/Research/TSG/SMLNET/
Regards,
Kennie
I refuse to do your homework for you, you CS slacker!!
E V E R Y T H I N G I W R I T E I S F A L S E
First I just wanna say why is there a sodding great ad for Visual Studio on a discussion about silver bullets???
:)
Now that I've got that out of my system I'll get on with it. I've been in this game for only two or three years now so I maybe completely out of line here, but I don't think there is such a thing as a silver bullet in the software dev industry.
Sure we have a wide range of tools some excellent, some just crap. However what it comes down to in the long run is the developer behind the tools. I use a plain text editor for most of my work for a couple of reasons, a) I know what code is going into my app and b) It forces me to know as much as I can about what I am doing. This suits me down to the ground.
When it comes to languages again there is no silver bullet. Each language has its own strengths and weaknesses. For sys-admin work I choose Perl, for Application level development I would choose C++, for Systems level development C and so on and so on.
It may just be me but becoming wedded to a specific language or toolset without looking at others is a sure fire way to lose ground quickly in this industry. The only thing that Im wedded to in terms of development is Linux (mind you thats partly to piss off the MCSE guy here).
QT GUI on Mac/Win/*Nix. And its gpl on mac and unix.
I think the tech market is very good right now. However, you have to look at it from the right perspective.
I'm in a tech company that has been growing over the last 3 years. The problem is knowing how to find business.
Every business wants to automate what they do. Every business wants to operate better and faster. The problem is, most tech companies know very little about how to actually do this, especially how to treat and care for customers.
Get to know the people and companies around town. Find out what their problems *actually are*. Find a way to fix them, possibly using technology. Present your solution and your price.
There are always people with problems that are willing to pay for them. What happened in the tech industry are:
a) it grew so fast, "developers" were in such demand that completely unqualified incompetents were being hired. In addition, HR had no way of distinguishing between competent and incompetent people. This is probably the biggest problem.
b) Even fewer people cared about actually serving consumer needs. Upgrading to Windows 2000 became more important than making my processes more efficient.
c) Management finally wised up and stopped doing useless things with technology. However, there is still a demand for useful technology, you just have to be able to justify it to a much smarter crowd.
d) Management refuses to go along with technology people who can't communicate.
Tech people are used to being able to just make sales based on the fact that they knew more about technology than anyone else. Now they have to be able to actually help solve problems. I see this as a good thing.
By the way, solving problems is something that can't be outsourced to third-world countries. It requires personal communication. It requires being able to see technology from the point-of-view of the business owner, and being able to speak intelligently and understandably about them and their problems, and only speak about technology when it's absolutely relevant.
Engineering and the Ultimate
Some of the other good things (C, debuggers, the Unix command-line interface) were there before 25 years ago.
Some things have been steps backwards:
And some bad things were already there 25 years ago (unrealistic schedules, buzzwords, complexity).
While hotspot server generates significantly better code, it spends much longer doing it and therefore the execution time is frequently worse.
If you don't believe me, try compiling some Java programs using javac with each VM. :)
A: No. First we had UNIX, then MacOS, then Windows. If that's not evidence for a decline in software quality, I don't know what is.
Nathan's blog
Why the hell would you be wasting your time even acknowledging a salesman. Not too mention letting one try to "manage" you. allowing such a thing demonstrates a total lack of confidence and assetiveness which adversely impacts ones employment in tough times. When the axe falls, the weak get cut off. You can be the best IT worker int eh world, in a corporation, you still have to demonstrate the traits which a corporation finds desirable in all workers.
Believe me, I try. I am an exemplary worker, and I can give employers outstanding referrals from former contracts and jobs I've had. I also have plenty of confidence in my skillset..but when your other option is not to work, or work in, say, retail, you will have to listen to even the biggest of idiots, especially if they are "in" with the company owner. Just because YOU have not been placed in this position (yet) does not mean it can't happen to you, and that situations like this aren't pretty common these days.
BTW: This sales guy was only managing for a short time, and it was a very small company. But he had to be tolerated because he was the buddy of the CEO. One of my co-workers was a complete nitwit, but she would go out of her way to kiss ass, while the rest of us would be actually getting things done, or cleaning up her mess. Guess who's still working, and who isn't?
Lastly, it's not the weak that *necessarily* get cut first. It would make the most sense in a free market economy if that were the truth, but reality isn't always that way. The brown-nosers stay to the last, I've noticed - the ones who play golf with the CEO/CTOs of the world, not the most competent. That's not to say that some chaff has not been done away at the beginning of this down market, but now it seems to me it's down to nepotists and brown-nosers who are keeping their jobs the most frequently.
I have worked with several competent people at contracts and I know the skill layouts at those places - the competent got cut, and less-than-able people were kept. It's not cost-cutting, it's more likely to be who is buddies with whom.
Successful software projects are not successful because of a particular platform, methodology, or soft drink. It's the people, and how they interact. In my view, success hinges on one thing: the management of expectation. User's expectations of the system and vice versa, management's expectations of programmers and vice versa, users' expectation of IT and vice versa. If communications of these expectations are clear, honest, and consistent, one's chances of success are improved by quite a bit.
All your points are very good and valid ones. However, the only people who can seriously effect a positive change are the people doing the hiring, and doing the "managing". If these folks continue set the bar of excellence by "X years using Y tool/language/methodology", then they will continue to get shitty workers, because even an idiot can stumble along at various jobs doing Y until he reaches X, and it's no measure of his talent, skill or knowledge.
I've also noticed that people who have fallen backwards into coding are often rewarded for their skills at brown-nosing or the gift of gab (the meaningless how's-the-weather type of chit-chat), and those who are really good at what they do, and can and do help others around them do better, are not always justly rewarded - in fact, I've been reprimanded for helping team members - I was told I "talk too much". In fact, those that are NOT in M0 seem to be rewarded the most, even if most of the team-members really despise working with these types of folks, because of all the crap code they produce.
I've recently had a few interviews and found the same old disturbing attitude among developers:
We think that the lower level our knowledge goes, the better developers we are. We think that by understanding all the gorey details of what goes on under the covers, we improve our value as software engineers.
Hogwash, I say.
For all the effort the industry has spent bringing us to a higher level of programming, it is confusing as to why we stick with our low-level eliteist attitude. What has changed my opinion over the years is having worked with:
1. Database engineers who don't know a lick of C++. They are good at what they do. But do they strive to understand how SQL Server or Oracle was written? No!
2. User Interface designers who don't know a lick of C++ but can ask the important questions pertaining to usability. Do they strive to understand how the TreeView control was written? No!
and so on and so on.
The funniest thing I have encountered was an engineer who could talk for hours on the ins and outs of Unicode. Yet, nothing he produced was globalizable. Another engineer just used best practices and probably couldn't tell you nearly as much about Unicode, but we had an easy time creating globalized versions of his app.
Go figure.
Incidentally IBM has pretty much always had a great VM as well....dont think its available on Solaris tho ;) Certainly works well on Linux and Windows.
I dont think any of the companies that do native compilers for Java offer trial versions which sucks and they're not cheap either. There are at least 4 companies and each product is better suited to certain types of applications (some server-side...some client, etc).
My blog: http://jkratz.dyndns.org/~jason/blog/
I have one question: when we all compare the speed of Java to C, are we necessarily comparing the JVM to a compiled C application? How does a natively compiled Java app (through GCC-Java) compare to a compiled C application?
I hope access to books were easier than it is currently. Thanks to the net I can have access to a lot of information for a low cost, but almost none access to the books you mention. Searching in IRC, Kazaa, newsgroups and other ''illegal'' sources you can find easily "learn visual basic in 24 hours", "microsoft word for dummies", etc, but not the truely great books.
I don't live in USA, so books for me are a lot more expensive. First consider transport cost, but don't forget relative prices. If you live in Boston you can make US$1800 cleaning bathrooms, but here for that kind of job you would be paid around US$150. That makes a big difference when you want to read a US$50 book.
GUI stands for graphical user interface and is a general term not a package/library name.
I've been working with computers for 30 years. assembler, Fortran, Pascal .. Java .. it all goes around. Each new generation tends to dismiss the leasson of its predecessors. It's quite funny after a while.
But we still come back to the basics. Make libraries (whatever they may be called - classes, even patterns). Use them. Design the system decently but not too much. Test the suckers. Try to get the end users to listen to you and stop changing everything all the time.
"Cats like plain crisps"
You sure you're not in an MBA program? "Quick and inexpensive" are not the key issues. How about quality and client value?
c
The advantage of type systems is that it is, in general, easy for programmers to figure out what kinds of things they expect ("This will be a name/int tuple... the next is either a function from int to int to int or nothing..."), and reasonably easy for compilers to infer the rest (so you can annotate your code and the compiler figures out where you're wrong-- and if you don't annotate, it'll still be able to figure out that you're wrong, just not quite as precisely where). I've now arrived at the conclusion that a programming language is worth using (as opposed to investigating) if and only if it does static type checking (with parametric types); that's just my opinion, of course.
Other advances have been in garbage collection (not having to worry about freeing your memory, manually keeping refcounts etc. is a major time-saver, prevents memory leaks, and keeps your code cleaner and more readable) and formal software engineering (e.g. done in VeriFun,
this allows you to formally verify that, given the semantics of your program, a certain statement holds-- while Hoare triples (as used e.g. in Eiffel) are somewhat useful, they're not quite as powerful as this.
So, if you want to write good software:
You can, of course, do the latter by hand if you don't have verification tools (or don't have them for your language of choice). The big problem with these things is that, while they tend to lead to excellent, readable and reusable code, they're harder to do than quick perl hacks which work 99% of the time and can be done by J. Random Hacker; also, you won't find many good ML or Haskell programmers-- mostly for reasons of legacy and popularism, I guess.
For reference, I rarely do the three things above. Formal correctness proofs are non-trivial, and the problem with statically typed languages is that it's (a) hard to find good libraries for them, because (b) very few other people use them (usual chicken-and-egg problem, I guess) and (c) most of my own legacy code is in those weakly typed languages, so I'd have to re-implement big chunks of code. If we're lucky, we'll one day see C and C++ and Java and Python and Perl die out, and everyone will start using statically typed languages, formally have their programs verified etc. If it happens, it'll be years away, but I believe that it's worth working towards this goal.
Common Lisp vendors, including franz missed the window of oppertunity during the impressionable years from 1983 to 1998. Even with making the tools readly available to universites, the commercial and per-seat licenses where expensive even incomparison to IBM's offerings.
Try none. Intellectual property laws have effectively hamstrung software engineering as an industrial process. While this may be great from a programmer's perspective (income potential and job security), it's detrimental to the industry as a whole. I've even run into situations where I've been unable to bring standard utility code with me from one job to another because the companies I work for are afraid of a lawsuit.
You have to accept the fact that the software industry is still it infancy. We're still working on a development process that allows for true compoment interchangability and programming by design rather than direction. The software industry is the same place now as it was 25 years ago. It's much like metalsmithing shortly before the industrial revolution. Everything is hand-crafted and trade-secrets are jealously guarded by companies, while programmers/journeymen are encouraged to attribute their skills to their company and not to leave to work anywhere else. Finally, basically no effort has been made at anything resembling component interchangibility (see: "intellectual property laws"). While mechanical engineering may have long since settled on the idea of basic compoment standards (you can go to any hardware store and buy a replacement screw for that thingamabob at home), only passing attempts have been made in the software industry and this only by a company who wants to sell their new "component solution."
This is one area where open-source software has the potential to fundamentally change everything, but until there's a way for programmers to make a living developing OSS, the change will be long in coming. Ultimately, companies may start to realize that jealously protecting knowledge/code isn't necessarily in even their best economic interest, but until then we have a future of hand-crafted software to look forward to. After you've re-created the same wheel 10 or 15 times it starts to get old. It's much more satisfying to be able to focus on the high-level problems without mucking in the minutae. IP laws may have been created to protect investment and thereby encourage innovation, but their actual effect is exactly the opposite.
Named parameters are nice as well, this is an alternative which has its advantages and disadvantages. If I had to choose I would go for the refactoring(s). They are more versatile, encourage improving your code and save some find/replace (well, a lot actually).
Named parameters is to *avoid* find-and-replace.
I consider refactoring one of major new OO coding techniques of this decennium
I actually consider this "refactoring" push a *failure* of OOP, or at least a bad idea. Rather than trying to avoid the Code Change Gods, it is giving into them big-time. I don't get it.
Table-ized A.I.
my grammar is retarded
The joke when I worked for a large aerospace company went something like this:
Generally, when people want to make a baby, one woman gets pregnant and you wait for nine months. Low and behold, after nine month and assuming nothing goes wrong, you have a baby.
Software development managers seem to be of the opinion that if you get nine women pregnant and puts lots of schedules on the walls and yell and scream alot that you can then produce a baby in one month. No matter how many times this approach fails, development managers refuse to give it up.
In their defense, I will say this company learned the "mythical man-month" lesson and stopped adding developers to late software projects. Instead, their approach was to add additional managers so there were more managers posting schedules on the walls and yelling that the project was late. I guess in some ways this approach really did work a little better since it got them around the adage that adding more developers to a late project only makes it later. Unfortunately, the additional managers all usually wanted status reports so the developers wasted more time writing status reports for the additional managers which still ended up making the project later.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
Something that people seem to forget is key, to quote a friend "software is made by people". People are inherently imperfect, as is code. Do not get me wrong, there is good code however in nearly every application there is something that could be improved.
Not many people would argue with that, and I think that this is key to why OOP isn't all that its cracked up to be. Essentially you are using code, undoubtedly written by a genius, as a block into your code. This component will be a little less stable than the previous one as more inaccuracies, redundancies, leaks, and unexpected behavior are introduced.
The whole process happens again and again until you have your application. This application is now bloated due to it containing reusable components that are general enough fro you to use however contain more features than you need. At the same time causing your code to be very shaky due to the sheer number of layers that it contains.
People are not perfect, and these imperfections only multiply exponentially as OOP and such practices are used.
Not a new concept by any means, but something that seems to apply very well to this discussion.
Granted there is the CMM levels, but again words mean nothing if not applied as intended (or just say that unenforced policy is just words). Many places I have worked at enjoy spending your tax dollars on bullshit while the actual product is seen as secondary. They wrap them up in fancy names then politely make excuses for gross negligence but the result is simply a broken system that does not deliver and that cost millions to "create." To solve this problem the government and the big contracting firms take the ethical road and improve the process... HAHAHAHA, gotcha! No, what happens is that policy is set forth to force that system down the throats of users regardless of what the results are. Basically all the bad that can come of standardizing but none of the good.
there are hackers, then programmers, then developers then engineers... these are not ranks and levels as much as different roles. However those become mere words when not understood and applied through intelligent and consistent policy and procedure. UML can be a horrible buzz word or it can be a great way to standardize representations. OOP can be a great way to abstract and reuse code or it can be just another nightmare of security and overhead. Remember that the best system in the world is nothing if used by monkeys, of which most modern management seems intent on setting as the standard for software development.
Is it just me, or does this sound like a college assignment that some professor gave out, and only one guy in the class had the balls to post it to Slashdot for research ?
Servlet v2.4 container in a single 161KB jar file ? Try Winstone
First off its C....not c. Secondly you can't make that claim.
The poster was right - it is c. c is the speed of light, and as we all know, nothing can go faster than that, so it follows that Java is slower than c.
8-)
I am CTO at an internet software company. I have worked in all kinds of environments, from COBOL on an NCR mini to FORTRAN on a Cray, and I have to say that Java has been a revelation. We do our core product in it, and all we have to do is write the application code - need a hashtable? No problem, just call the library. While I think people should understand how the tools they are using work (which VB kids often do not) having tools rocks.
The key challenge that still hasn't been addressed is that 90% of the people writing software are still amateurs, in the sense that they do not have a computer science education. Just as you expect a bridge designer to have a degree in structural engineering and some postgraduate certification, the software industry will necessarily go the same way if it is to be successful. That doesn't stop you from putting up your own tool shed in the back yard (c.f. little toy db with MS-Access, quick Perl CGI, etc.) but the core industry churning out code on which $tn's of our economy relies needs to turn professional - let alone safety critical stuff like ABS controllers and ATC.
I'm not much of a programmer so i can't comment on actual programming improvements but one common thread i saw was that large libraries of code has been a huge boon to development. Big Blue Box has developed a system of organizing its seperate projects. (They develop computer and console games) Each project or brandname product they have gets spawned as a small group or satelite company. The first example was that they have spawned off their Black & White studios to work on that game line.
How they use this is called the satelite system. Every month the seperate companies/groups meet and share their ideas and what they have done with each other. They can get the viewpoint of many different developers that way. They also can share code between them. One example was that one group developed some awesome water effects. (looks damn close to real water) They all now have access to the great water renderer. Sharing code like this allows less programers to create more together. Its the same idea as having large online libraries of code at your hands. (another advantage to this system is that it is easy to intergrate a new small team of developers and give them access to large amounts of code to get started.) I can see this as a method that will take off in the near future.
Now all i have to do is to train my sheep to sort through my spam...
Which just goes to show how some people like to think everything in the world is *somebody elses* problem. ;)
/will/ be a silver bullet in the next few decades, it's called EDUCATION and MATURITY. Once people begin to understand the full ramifications of computing (just as ram-raiding is one of the ramifications of automobiles) then people will start developing a more mature approach to buying computers, which means the industry will either improve or get regulated once groups of people are actually willing to vote on that issue alone.
;)
Programmers are not the biggest problem - CUSTOMERS are. You wouldn't buy a car if they welded the hood shut and tried to throw you in jail for working out what was under the hood? Yet you *will* buy the swill some people call software and claim it is any single companies fault for providing exactly the cheapest product the market will support (since anything less will get them undercut by someone who is willing to publish crud).
There
Unless of course you can think of any single entire industry which *independantly* decided to improve itself for the good of humanity?
Java like any object-oriented language is difficult for an expert C programmer to learn. It is not difficult because it is better or worse but because the development process is completely different. If you are an expert C programming a lot of what you have learnt/understand to be true about software development will be wrong or will not apply. Many things you consider unimportant are very important when you go to object oriented development. It is actually much harder to change from the functional -> object-oriented paradigm then to start from an object-oriented paradigm. This is why so much bad object oriented code has been written i.e. why Java is slow. If you can't write fast Java code you don't understand or are unable use the object-oriented paradigm. If you persist and learn your programs will become faster and more robust.
Complexity is a bit of an illusion, the standard C library is complex but once you understand it you can make massive reductions in the complexity of you programs. This is the same with standard java classes. There are a lot, but with them you can make massive reductions in the complexity of your code, with the added advantage that the standard java classes are already documented and well tested, which reduces your work. It also allows you to defer many decisions till later in the development. e.g. will it be an array or a linked list, or should I determine this at runtime.
I just took a look at your website. Judging by the books you've written, it seems like you're skilled. I can't believe you're only charging $20/hr for consulting services... how do you eat?
I know some people use languages in which programs can be proven to work like ML
Oh, the languages can be proven to work, eh? When you produce a compiler that can prove that your *arbitrary* program ever stops, much less does A, B, or C, come see me, because we'll have tons of fun turning the entire mathematics and computer science worlds upside down.
If you just mean human-provable, and only for small non-arbitrary programs, that's quite doable with C or any other language. ML makes it slightly more structured, which is convenient, but doesn't give you anything that you couldn't do with C.
May we never see th
Let me prepend this by saying that I really do not like ocaml or other ml languages, but if you're into functional languages, you may like it. There are some things that are done right, like a very strong type system.
Unison, a file-sychronization tool, and MLDonkey, a P2P client that supports just about every significant P2P protocol out there (except the closed version of FastTrack) are both written in ocaml. That's all I know of, though.
Give me something like ocaml but without type inference (most annoying invention of all time) and not a functional language (sorry, just don't think that way), and I'd be pretty happy. It's about the fastest safe language out there, followed closely by eiffel.
May we never see th
-Kevin
Is this supposed to be an adv for Executable UML. It does exactly this.
In a tangential manner, you've hit upon what's the real problem. As long as software developers cede their craft and their profession (and their sanity) to the market desires of big software development companies rather than what's best for computer science, these stupidity cycles will continue dragging us all round and round and round. It's high time for a powerful programmers' guild that not only takes on poor software development management, but also software development companies that push their own selfish/myopic agendas over what's technically/financially best for the organizations we work for.
Steve Magruder, Metro Foodist
Yes. And most of them are from India. ;)
Wake up man. :-D
Hmmm... Ok.. Chivas on the rocks.
Server side java (I sneer at your capitalization), is not extremely fast, it is extremely adequate on modern hardware for low volume websites. You'll have quad processors with a gig of ram before it even comes close to the ability to handle the load of a pentium 2 with 128 megs using a lowly interpretated language like perl, and once you start to scale (load balancing, clusters, caching), java really falls behind a native solution. It's only because it runs on bigger hardware than many apps, and that there is more enterprise infrastructure, cheaper that java has any success.
And I like java. Because I'm not good enough to be a good c programmer.
Most companies see the small performance loss from using object oriented languages does not compare to the loss in man hours maintaining non-OOP code.
While this is true, it does not invalidate the point that there is a general obsession with over-inheritance, especially among novices. Overuse of inheritance also leads to situations where code flexibility is reduced or the implementation becomes quirky.
I prefer to use switches where I see no significant benefit in capabilities with inheritance and I can assure myself that:
except that a vm will never be as stable as the native os, even with a perfect vm, there'll still be bugs in the os that it exposes. Oh, and java has a very long way to go before memory is handled as efficiently as it could be.
there's the rub. Caching isn't really a good option in java, because it is such a memory hog, and because allocating and deallocating is so inefficient. PS. JWT isn't java, its an interface to native toolkits.
Concurrent GC? What's that?
WeRelate.org - wiki-based genealogy
My dream system would be something like what you've said, except the functions would be stored in a language-independent manner (okay, Perl's probably out). When you need a function, 'fvs' would generate code in the language of your choice.
Remember Genera, or the other LispM OSes?
Those operating systems were written in Lisp to about the same extent that, for example, Linux is written in C, that is, about everything except some assembler parts was Lisp.
In fact the whole point of the Lisp Machine and its derivatives was exactly that the assembly language was Lisp. Certain instructions and data types were directly supported by hardware. Others were trapped and handled by an implementing routine, microcoded using the directly supported instructions. In this respect the Lisp Machine OSes were much like modern Lisp family languages: In those languages, the interpreter or compiler supports a subset of the language directly and the rest of the language is built using those primitives. In a Lisp Machine, a subset of Lisp is supported directly and the rest is built on top.
Exactly the same language was used for the entire O/S, all applications, and user level scripting in a Genera system. Maybe someday when Star Trek comes true, such a wonderful system will again be available.
Here's more detail:
tuning JVM v1.4.x+
Any good C programmer would have done OOP in C (maybe without knowing it) before he switched to a "proper" OO language. Some aspects of OOP are easy in C , eg by using function pointers in structures to mimic methods and inheritence. The problem learning OOP languages is more due to their appalling design and syntax, I mean was Bjarn on drugs or something when he came up with the C++ template syntax?
You guys must be geniuses or something.
It's probably way to late to bring this up, but, yes, Java can and probably will beat C++ performance. There are two basic reasons:
First, Java byte code operation is specified completely. This means that is a calling tree never calls any sort of native method implementation, the optimizer can play 'fun with graphs'. This gives the optimizer the oportunity to use tricks like non-blocking I/O, and aggressive inlining. Most importantly, it allows register optimization across method calls. In C/C++, optimizing across method calls runs afoul of odd and random pointers.
Second, Java can reoptimize based on current runtime usage pattern. Imagine a banking transaction program that processes a million checks and deposits. Cashing a check involves looking up the account, withdrawing the money, applying overdraft, etc. In reality, 99.99% are correct without overdrafts. The Java optimizer rewrites the code as 'look up account or panic, then subtract check amount from account leaving a positive balance or panic'. The program is shorter and can make better use of registers in the usual case, and the 'panic' means to unwind the optimized code back to the Java byte code. This beats C++ when you do a million checks followed by a million deposits.
There really is a much larger theoritical cieling for Java optimization. It comes with the cost of stepping back from the hardware.
You'd change compilers for a 2x improvement in speed? You'd get that in better machinery before you could get really proficient on the new compiler.
Give me a good set of comprehensive libraries, and I can create solutions in Fortran VERY quickly.
Perl is nice. I'm in the process of learning it myself. But don't give it too much credit.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.