ArticleS. UncleBob.
TheNextBigThing [add child]

The Next Big Thing

The history of software development has been punctuated by one revolution after another. In the late '60s there was the modular programming revolution. This was the first of the adjective/programming pairs. It was not to be the last.

In the '70s we had the structured programming revolution, followed very quickly by the structured design and structured analysis revolutions. Interestingly enough the three 'structured' words have very different meanings. The structured in structured programming was not the same structured that was in structured design, or structured analysis. The concepts were completely different. This was the first time that a word in our industry became synonymous with "good" and then trifurcated into the waterfall triplet of analysis/design/programming. It was not to be the last.

In the '80s we had the object-oriented programming revolution. One of the great reasons for the success of this revolution, other than the vast technical superiority of the the OO techniques, was that the abbreviation OO comprised the middle two letters of the word good. The waterfall trifurcation was quick to follow. By the late '80s we had OOD, followed swiftly thereafter by OOA. Indeed, Pete Coad wrote three books entitled, OOA, OOD, and OOP.

To this day I don't think there is a reasonable definition of OOA. But then that's not surprising, since I don't think there is a reasonable definition of Analysis. We don't know what it is, but we know we have to do it. We also know that if XYZ is good, then there needs to be XYZ-Analysis.

The change of the millenium brought the next big thing. XP and Agile. (Can anybody out there tell me the difference? Really?) The hype was bigger than ever. The ruckus in the nascent blogosphere was deafening. To this day, XP is the only topic I know of in computer science that has inspired books with bad Beatle song parodies and pictures of Groucho Marx.

The Agile revolutionary big thing came just in time for the dot bomb. XP/Agile had just gotten going. The hype engine was roaring at full tilt. And then the industry froze in place for nearly four years.

A year ago we chipped our way out of the ice, to find a bleak and barren landscape. But the sun was shining, and little plants and animals were stirring from their long winter's sleep. Trade shows started making money again. Magazines started getting thicker again. Consultantcies were able to stop selling hot-dogs on the side. Life started to return to normal.

And then the question was asked. "What's the next big thing?"

Oh there were lots of next 'little' things. There was Web services, and SOA, and Components, and SOAP, and .NET, and well just a whole bunch of little things that everybody hoped might be the NBT. But none of them were as universal, as compelling, as noisy, and as self propagating as the previous NBTs had been. They were all really just more of the same, and nobody could really get too excited about any of them.

So the question, when it was asked, was valid. Even though there had been a plethora of little things during the ice age; none of them really amounted to anything truly revolutionary. So the question echoed hollowly over the landscape:

"What's the next big thing?"

"What's the next big thing?"
"What's the next big thing?"

I, for one, hope there isn't a next big thing. Or rather, I hope the next big thing is the big thing that we've needed for the last thirty years and haven't had the guts to actually say. I hope the next big thing is professionalism. Perhaps a better word would be Craftsmanship.

Let's face it. Our industry is hideously unprofessional. What other industry ships the kind of crap to their customers that we so regularly do? What kind of industry can make a $170,000 dollar mistake in requirements? We can call this the software crisis if we want to; but the crisis is really one of professionalism.

Don't get me wrong. There are some very professional programmers out there. There are professional teams, and even professional software companies. But they are the exception, not the rule. The rule, the exasperating repetitive depressing rule, is that software products are late, over budget, and buggy.

Companies who hire programmers don't really know what a programmer is, so they hire just about anybody and tell them to write code. Then they don't look at the code they write. They just let them hack away until, five or six years later, a few of them realize that cut and paste might not be the best way to build a system.

One would think that the schools might help. One would think that a degree in computer science might mean that the graduate could write code. One would be wrong. Many CS grads wrote little or no code in order to get their degrees. I find this astounding; but nevertheless it is true. The CS degree means very little in terms of programming ability.

Some think that the solution to this is certification. I think certification would be a disaster. We don't know enough about programming to certify it. I am deathly afraid of what a certifying body might require of a programmer in order to certify him. They could require that the programmer follow the waterfall process! They could require that the programmer draw UML prior to writing code. They might not require that the programmer write unit tests prior to writing code. The state of our practice is still too much in flux to think that we know enough to certify programmers.

But that doesn't mean we can't act like professionals. That doesn't mean that we can't decide, as an industry, that we will not ship shit.

I hope the next big thing is a consolidation of what we have learned over the last forty years. I hope the next big thing is the realization that software is not about hours worked, but about care. I hope the next big thing is the gradual understanding that developing good software is not about man-hours and raw labor; but about creativity, inventiveness, and a drive for elegance and beauty. I hope the next big thing is a change in attitude from big vanilla software groups, to small energetic teams. I hope the next big thing is the growth of professionalism and craftsmanship, and the realization that these are the attributes, not documented process or raw manpower, that will make our industry productive, accurate, and respected.


I am one of those Engineers, stability *Hah*, I don't think so. I'm one of those people that hire programmers to do my bidding. I think of it as art work. I commission that program (Art Work) to be done. For any software not to be "shit" you need a few things early on. Program direction, architecture, correct testing, and the person heading up the project needs to have a fundamental understanding of the process and desired outcome. Most crappy software seems to have a moving target which is always difficult to hit the first, second or even the third time. To err is human, to not divine. I haven't met a divine programmer yet. Now I've met a few that thought they were. Hence their idea of testing is, if it compiles then its correct.

I think a lot of programmers are hired, given poor requirements, have no earthly idea what there coding. I've been making my coders, designers test their work, and fundamentally understanding what they are doing. Its improved the outcome tremendously. Is it perfect, no, are there bugs yes. Are the bugs minimized hopefully.

As with many things coding software is an iterative process. Just as Engineering follows this concept, software follows it as well. Its called spiral design. To me professionalism follows a few rules. 1. Don't dismiss any ideas, off hand. 2. Be open to change. 3. Do not be hurt by criticism, learn from it. 4. Don't be scared to bring up ideas and concepts. 5. Always try your best and 6. Don't be afraid to ask for help or ask the conceptual guy/project lead "what the hell are you thinking"

I have no idea what they are teaching in programming classes these days. When I went to school/college, we had card punch/card readers and main frame computers. I guess that dates me a little. Trust me even the buggy, crappy software is a hell of a lot better than doing it by slide rule, type writer, or by hand. I just wish the folks that know there is a problem with their software would take the time to fix it, instead of ignoring the problems (I wont provide and example "Microsoft")

2005 2 22, Kelley Harris - You're onto something big here Bob. This developer hungers for working on a "small energetic team." I hope that as more small energetic teams win bids and complete successful projects, the broader software industry will eventually notice. ("Example isn't another way to teach, it is the only way to teach." - Albert Einstein) In the interim world of too-busy hiring managers and too much e-mail, it seems we need some way to quickly identify professionalism and craftsmanship, if professionalism and craftsmanship is going to be valued, hired, and rewarded. ($150K-$400K vs $50K-$100K) It seems like some type of certifications would provide useful info. (ex. Certified in Design Principles level 1, by Object Mentor 2005) Thanks for writing on this topic. Looking forward to hearing more.

Regarding what other industry ships crap... the movie industry? And there are probably a lot of construction disasters out there. Having said that, +1 on professionalism.

I hope the Next Big Thing is actually small, at least in complexity (a collection of simple ideas can still have a far reaching scope)
I hope the Next Big Thing can be learn't and applied in a bitwise manner, start using at a bit and then more as confidence grows (rather than an all or nothing thing)
I hope the Next Big Thing is named in such a way that it is impossible to make a buzzword or catchy TLA out it or even generate jargon from it. (rendering it impossible to gain
an air of 'Next Big Thingness' without actually doing it)
I hope the Next Big Thing is anti-guru (it is not contreversal or convoluted enough for anyone to make a living out of training or writing books etc. about it)
I hope the Next Big Thing is relatively universal (generous enough to be applicable to a wide range of technologies and situations without relying on the quirks and or foibles of single technology)
I hope the Next Big Thing is complete (no possibilty of Next Big Thing.2.0). Not inflexible however (adaptability is built in from the start)
I hope the Next Big Thing is fun!!!!
I hope the Next Big Thing has no concept of original sin (it engenders no feelings of guilt about the Non-Next Big Things that came before).

>>What kind of industry can make a $170,000 dollar mistake in requirements?

I am pretty sure that there were so many mistakes in requirements in almost every industry: Aerospace, Automobile, Electronic and so on. I don't think software development is an exception.

Our industry just young. That's all.


 Mon, 13 Jun 2005 02:06:46, Brad Appleton, Aspects have now followed-suit in completing the waterfall triplet
I notice that, within the past year, Aspect-Oriented Programming (AOP) and Aspect-Orientation has now "trifurcated", completing the waterfall triplet: the last few years have seen books and articles on Aspect-Oriented "Design", and within the last 6-8 months we have a book on "Aspect-Oriented Analysis and Design" ( and another on Aspect-Oriented Use-Cases (

I wonder if the trend we're seeing isnt so much aspects, but the same trend indicated by Charles Simon Yi's emphasis on Intentional Programming (he now calls it "Intentional Software" -- see, and by the emphasis on Domain-Specific Languages (DSLs) in Microsoft's "Software Factories" (, and to some extent even eXtreme Programming's representation of tests as precise requirements specification, and the way ObjectMentor[?]'s own FitNesse framework is almost a DSL-like front-end for that.

I think programming languages and software specifications have evolved beyond the domain of the coder and designer into the domain of the analyst and the customer. And I wonder if the next "big thing" is perhaps the ability to use what we've already created for design (encapsulation and dependency management via objects, patterns, aspects, etc.) but in the domain of "customer-orientation" in terms of how we gather and maintain "acceptance tests".

See for more details.
 Wed, 22 Jun 2005 02:22:02, Curt Sampson, It's not the programmers.
Having done XP for a few years now, the problems I see are not lack of professionalism or craftsmanship in programmers, though I have seen that. The biggest problem is the lack of professionalism and craftsmanship in customers. They're not willing to do the work necessary to be a good customer; they just want some magic to happen such that the programmers write code and everything comes out ok. No matter how good a development team you have, in such a situation the customer is not going to get the right product, except by luck.
 Thu, 23 Jun 2005 19:57:43, Joe Merlino, It gets worse
I'm consulting at a company that doesn't use version control. When I suggested that we really need version control to simplify the team development effort and improve efficiency, they look at me like I just said something bad about their mother. This is just one example of the projects I've worked on that feel that fundamentals like design, best practices, testing, and even relational databases impede the progress of the project. Has anyone else run into this kind of thing?
 Tue, 28 Jun 2005 11:43:25, Glenn Taylor, Anybody can program...
Any high school student that learns BASIC or Pascal or whatever is a programmer. I have fought that logic for my whole 25 year career. I went to college not just to learn to code, but to know how to develop software. Ok, we didn't learn patterns or XP, but we learned structured programming and data structures and a little compiler theory. All industries have technical changes that must be kept up with. The issue I've struggled with is that the person that can string IF and FOR statements together without compiler or run-time errors is called a programmer along with the rest of us. Developing software has way more to it than coding. There are concepts of efficiency, maintainability, and teamwork. There are networking, database and user-interface concepts that must be learned (or at least allowed for). Coding is just a small part of the actual job of delivering a non-crappy final product. Oh yeah and there's documentation, communication skills, marketing and many other skills that need to be maintained by a developer.

If a person graduated from high school and took physics and math there and then went to a bridge design company or an electronics firm, they would get laughed at. They know some of the fundamentals of mechanics or electronics, but are not even close to being qualified to build bridges or design electronic equipment. The software industry is the only one that I know of where the equivalent happens. Once I read a book on Java and can string code together that compiles, I'm qualified to work in most software shops or to become an independant consultant and start developing applications. We have no licensing or certification processes like engineers, health workers, food workers or auto mechanics.
 Tue, 25 Oct 2005 17:31:46, Luis Sergio Oliveira, NBT does not exist
My take on this is that there is no NBT. What you have in engineering disciplines is gradual improvement of the techniques with some new innovations being brought once in a while. A new technique is normally selected by a group of professionals, being used correctly by some and abused by many.
Heck, you just look at how Agile term is being abused today. We have actually very few persons understanding fully what it stands for even in software development.
For instance, were / are Agile or Agile methodologies a NBT? Certainly if you are a pushing consultant or book author that make tons of money out of it. Is it for the industry as a whole? No. It is a new technique that properly applied may give good results.
I'm very new to the industry (5 years) and I come from a wrong background (Physics) - as Glenn states, but, after reading the old book by Dr Brooks (The Mythical Man Month) I know that many of the present and future mistakes were correctly identified decades ago. One of them was don't expect for the NBT in some of the upcoming decades! So, maybe we should ask: how can such an innovative and full of bright people field keep making the same mistakes over and over again?
Maybe because in almost the whole world there is no such thing as Software Engineering degrees, but, things like CS and IT Engineering.

PS: don't take me as bashing Agile methodologies like XP and TDD or AOP personally I think these are bright new ideas that could do much good to the industry, they are simply NOT the NBT because there's no such thing.

 Tue, 27 Dec 2005 22:08:53, R Scott, NBT: An old practice applied to a "new" industry
I like the professionalism / craftsmanship idea and the arguments that followed it in the headliner article.

The problem with software is that it is really BOTH: "Science" and "Art". Science you can figure out, define, measure, and even prove… (requirements). Art? No way, man! That’s all black magic, smoke, and mirrors. Art is really the aspect of software that businessmen, planners, methodologies, standards so much want to get under control -- and how do you define Art? (I can, but that is a philosophical process outside this scope. Unfortunatly for me, when I did software, I was more entranced by beauty over engineering).

I think the guys going after certifications are onto something. How can a judgment call be made about a professional? Observed acts over time show patterns about a person and it is something that can be measured. (Who can possibly know what is in the mind)? Thus, the college degree proves something about a person. So do advanced degrees. Certifications from institutions also mark educational/experiential milestones. Even though things like these can't tell you about a person -- "Really" -- they are all we have at present.

Perhaps the NBT will be more in the area of Federal or State licensing of software professionals and then their periodic "Credentialing". Yes, like healthcare (and other) professionals. Why? Hey! I think software rules! And when those planes start falling from the sky; trains run off the tracks; power stations start winking out; cars start..., traffic systems begin..., communications systems start to... What? Oh yes, software affects so much of human LIFE and potential DEATH! It's because of that aspect, solely, that the powers-that-be especially want, no, need to get a grasp over software.

Federal licensing and Credentialing provide a healthcare professional's entire "Curriculum Vitae" in such a public, somewhat consistent and on-going manner that, over time, those that loose their skills or have moral lapses get weeded out of the system. It's a balance to the doctor's power over life and death that this is so.
 Wed, 31 May 2006 13:06:16, rape stories, hello
Best of the text i read about a problem.