Monday, October 12, 2009
"Agile is treating the symptoms, not the disease"

The above quote was tossed off by Billy Hollis at the patterns&practices Summit this week in Redmond. I passed the quote out to the Twitter masses, along with my +1, and predictably, the comments started coming in shortly thereafter. Rather than limit the thoughts to the 120 or so characters that Twitter limits us to, I thought this subject deserved some greater expansion.

But before I do, let me try (badly) to paraphrase the lightning talk that Billy gave here, which sets context for the discussion:

  • Keeping track of all the stuff Microsoft is releasing is hard work: LINQ, EF, Silverlight, ASP.NET MVC, Enterprise Library, Azure, Prism, Sparkle, MEF, WCF, WF, WPF, InfoCard, CardSpace, the list goes on and on, and frankly, nobody (and I mean nobody) can track it all.
  • Microsoft released all this stuff because they were chasing the "enterprise" part of the developer/business curve, as opposed to the "long tail" part of the curve that they used to chase down. They did this because they believed that this was good business practice—like banks, "enterprises are where the money is". (If you're not familiar with this curve, imagine a graph with a single curve asymptotically reaching for both axes, where Y is the number of developers on the project, and X is the number of projects. What you get is a curve of a few high-developer-population projects on the left, to a large number of projects with just 1 or 2 developers. This right-hand portion of the curve is known as "the long tail" of the software industry.)
  • A lot of software written back in the 90's was written by 1 or 2 guys working for just a few months to slam something out and see if it was useful. What chances do those kinds of projects have today? What tools would you use to build them?
  • The problem is the complexity of the tools we have available to us today preclude that kind of software development.
  • Agile doesn't solve this problem—the agile movement suggests that we have to create story cards, we have to build unit tests, we have to have a continuous integration server, we have to have standup meetings every day, .... In short, particularly among the agile evangelists (by which we really mean zealots), if you aren't doing a full agile process, you are simply failing. (If this is true, how on earth did all those thousands of applications written in FoxPro or Access ever manage to succeed? –-Me) At one point, an agilist said point-blank, "If you don't do agile, what happens when your project reaches a thousand users?" As Billy put it, "Think about that for a second: This agile guy is threatening us with success."
  • Agile is for managing complexity. What we need is to recognize that there is a place for outright simplicity instead.

By the way, let me say this out loud: if you have not heard Billy Hollis speak, you should. Even if you're a Java or Ruby developer, you should listen to what he has to say. He's been developing software for a long time, has seen a lot of these technology-industry trends come and go, and even if you disagree with him, you need to listen to him.

Let me rephrase Billy's talk this way:

Where is this decade's Access?

It may seem like a snarky and trolling question, but think about it for a moment: for a decade or so, I was brought into project after project that was designed to essentially rebuild/rearchitect the Access database created by one of the department's more tech-savvy employees into something that could scale beyond just the department.

(Actually, in about half of them, the goal wasn't even to scale it up, it was just to put it on the web. It was only in the subsequent meetings and discussions that the issues of scale came up, and if my memory is accurate, I was the one who raised those issues, not the customer. I wonder now, looking back at it, if that was pure gold-plating on my part.)

Others, including many people I care about (Rod Paddock, Markus Eggers, Ken Levy, Cathi Gero, for starters) made a healthy living off of building "line of business" applications in FoxPro, which Microsoft has now officially shut down. For those who did Office applications, Visual Basic for Applications has now been officially deprecated in favor of VSTO (Visual Studio Tools for Office), a set of libraries that are available for use by any .NET application language, and of course classic Visual Basic itself has been "brought into the fold" by making it a fully-fledged object-oriented language complete with XML literals and LINQ query capabilities.

Which means, if somebody working for a small school district in western Pennsylvania wants to build a simple application for tracking students' attendance (rather than tracking it on paper anymore), what do they do?

Bruce Tate alluded to this in his Beyond Java, based on the realization that the Java space was no better—to bring a college/university student up to speed on all the necessary technologies required of a "productive" Java developer, he calculated at least five or six weeks of training was required. And that's not a bad estimate, and might even be a bit on the shortened side. You can maybe get away with less if they're joining a team which collectively has these skills distributed across the entire team, but if we're talking about a standalone developer who's going to be building software by himself, it's a pretty impressive list. Here's my back-of-the-envelope calculations:

  • Week one: Java language. (Nobody ever comes out of college knowing all the Java language they need.)
  • Week two: Java virtual machine: threading/concurrency, ClassLoaders, Serialization, RMI, XML parsing, reference types (weak, soft, phantom).
  • Week three: Infrastructure: Ant, JUnit, continuous integration, Spring.
  • Week four: Data access: JDBC, Hibernate. (Yes, I think you need a full week on Hibernate to be able to use it effectively.)
  • Week five: Web: HTTP, HTML, servlets, filters, servlet context and listeners, JSP, model-view-controller, and probably some Ajax to boot.

I could go on (seriously! no JMS? no REST? no Web services?), but you get the point. And lest the .NET community start feeling complacent, put together a similar list for the standalone .NET developer, and you'll come out to something pretty equivalent. (Just look at the Pluralsight list of courses—name the one course you would give that college kid to bring him up to speed. Stumped? Don't feel bad—I can't, either. And it's not them—pick on any of the training companies.)

Now throw agile into that mix: how does an agile process reduce the complexity load? And the answer, of course, is that it doesn't—it simply tries to muddle through as best it can, by doing all of the things that developers need to be doing: gathering as much feedback from every corner of their world as they can, through tests, customer interaction, and frequent releases. All of which is good. I'm not here to suggest that we should all give up agile and immediately go back to waterfall and Big Design Up Front. Anybody who uses Billy's quote as a sound bite to suggest that is a subversive and a terrorist and should have their arguments refuted with extreme prejudice.

But agile is not going to reduce the technology complexity load, which is the root cause of the problem.

Or, perhaps, let me ask it this way: your 16-year-old wants to build a system to track the cards in his Magic deck. What language do you teach him?

We are in desperate need of simplicity in this industry. Whoever gets that, and gets it right, defines the "Next Big Thing".

Monday, October 12, 2009 10:48:55 PM (Pacific Standard Time, UTC-08:00)
I'd say that PHP and Ruby on Rails are this decade's MS Access.

In terms of the area where agile methodologies provide value on the graph you mentioned above, even small shops with half-a-dozen developers can start to see improvements. I know that the scale card is played far too often, but that isn't necessarily an "agile thing". Architecture Astronauts are just as susceptible.

I'm not sure I'd say that the technology complexity load is the root cause of the problem, but rather that preoccupation we have with technology - rather than actually solving the problems at hand, that is likely to be closer to the root.

I am very much in agreement that we need to drag out into the open the unspoken assumptions people have about "agile" and technology and take a long, hard look at them. Nice post.
Tuesday, October 13, 2009 12:13:51 AM (Pacific Standard Time, UTC-08:00)
Great post, I completly agree. We have to look for simplicity again.
When you look at history, you notice that all this complexity comes with the accession of OOP. Could it be a coincidence ?
The OOP has definitly mixed technical and business stuff, and that's the disease.
I think the "Next Big Thing" will have to do with non-OOP approach, with focus on clear separation between functionnal and technical code.
Tuesday, October 13, 2009 12:43:47 AM (Pacific Standard Time, UTC-08:00)
This is so true... I totally agree... Please tell me the answer :) I'm not a professional developer, I write code from time to time for proof of concept type stuff and it is so difficult keeping up, and it's exactly as you say.

I was trying to knock up a simple dashboard using silverlight, and the hurdles have been: "silverlight requires asynch callbacks -- go learn WCF to create a proxy, whilst also knowing web services/SOAP/authentication/etc"; "I need to make a custom control to display the results because one doesn't exist for what I want -- learn Expression Blend, publicly exposed properties/etc."; "the custom control doesn't play nice with datagrid because for some reason, binding doesn't call the accessors -- learn about Dependency Properties etc.".

And this is just the start Needless to say, I'm nowhere near having this up and running... In the meantime, I've got to get on with my normal day job... Sorry for the rant... It's just this article really hit the spot...

Thanks ;)
Tuesday, October 13, 2009 5:00:50 AM (Pacific Standard Time, UTC-08:00)
"Keeping track of all the stuff Microsoft is releasing is hard work: LINQ, EF, Silverlight, ASP.NET MVC, Enterprise Library, Azure, Prism, Sparkle, MEF, WCF, WF, WPF, InfoCard, CardSpace, the list goes on and on, and frankly, nobody (and I mean nobody) can track it all."

You are looking at this a bit one eyed. There is another reason then a pure technology one for more stacks. Business has changed, today business crave more from the applications then they did in the 80s, today business have more complex demands on IT then in the 80's, today for a lot of company, their business wouldn't exist without IT (and I'm not talking about the companies selling IT).

Our profession is changing, requirements are changing. To ensure we can meet all these requirements we really need a lot of options. Both for the one man shop and for the enterprise. No one says you should use the enterprise tools for a small website, but knowing what options you have you might not try to build big scale with small tools.

Me and Johan Lindfors, DPE manager at Microsoft sweden. Did a duo blog about this recently:
Tuesday, October 13, 2009 6:41:15 AM (Pacific Standard Time, UTC-08:00)
PHP seems pretty simple.
Tuesday, October 13, 2009 7:21:11 AM (Pacific Standard Time, UTC-08:00)
Agile is a remedy for a disease in IT/Devs interacting with the business.

It doesn't make developers rockstars who can learn all of this stuff quickly. That is an entirely different problem that Agile should not be concerned with addressing (unless you think pair programming can cross train effectively to help with that curve).
Tuesday, October 13, 2009 7:26:10 AM (Pacific Standard Time, UTC-08:00)
Great post, agree on most the things you wrote.

The work that Jonas Boner is doing with Scala goes in that direction, ruby frameworks like Sinatra are also going in that direction.

Still, it can be simpler, it can be always simpler.

Shooting for simplicity is the key.
Tuesday, October 13, 2009 8:40:48 AM (Pacific Standard Time, UTC-08:00)
Interestingly I have had a few people recently telling me that they love Classic ASP because it doesn't require nearly the complexity and barrier to entry that ASP.NET does. More here:

And, oddly enough, I just asked about what programs are out there to manage Magic decks on SmarterGamer - did you see that question? :)
Tuesday, October 13, 2009 8:59:19 AM (Pacific Standard Time, UTC-08:00)
Three words: Domain Specific Languages. For the next decade though.
Tuesday, October 13, 2009 9:01:08 AM (Pacific Standard Time, UTC-08:00)
Where is Access?

Floating out there...

If you are willing to give up that last 1-5% of customization, it's all out there...
Tuesday, October 13, 2009 9:07:34 AM (Pacific Standard Time, UTC-08:00)
I want to give you a big hug now.

Well said.

I can't add anything except +1
Tuesday, October 13, 2009 9:20:42 AM (Pacific Standard Time, UTC-08:00)
The punchline of this post is based on the fundamentally assumption that it's technology which is causing the complexity in our corporate applications. I grant that there is certainly room for our technology to improve, and that we are in a phase of radically simplifying technologies instead of growing the power of them: the case in point is the ever-growing popularity of the development-by-convention approach spearheaded by Ruby on Rails. Development by convention and reasonable defaults are the new architectural must-haves for projects.

Ultimately, though, there's a core of difficult real-world problems which these technologies solve. Corporate environments are complicated places with up-time requirements that make chewing gum and bailing wire solutions unacceptable, and that is where this alphabet soup of technologies come from. In addition, there's a lot of tricky standard functionality which companies don't want to spend the time to re-invent (especially since they're likely to re-invent them badly). Transactional messages are critical when you have systems that need to reliably communicate, but writing such a system is very tricky, and so we have JMS. People adhere to conventions like REST to make APIs less surprising for the users and more obviously extensible. When I hear people touting "simplification" and calling these technologies "enterprisey", I really hear their ignorance coming out: while I totally agree that there are times when the technologies are overkill, these technologies are predominantly in place to solve hard problems.

Your example proves this precisely: there's an Access database out there, and it's written by one person and works for one person, but as soon as you add the complexity of wanting to have multiple people involved (especially multiple people of varying technical expertise and business perspectives), the situation just became a whole lot more complex. Building a bridge across the stream in your back yard may involve two 2x4s and work just great, but there are different problems involved when you try to cross the English Channel. It's simply missing the point to claim that the English Channel bridge building effort is in drastic need of simplification because it's not just made of 2x4s.

So we're stuck with a large swath of information that people are going to need to know beyond the basic intellectual understanding of algorithms.
Tuesday, October 13, 2009 10:23:28 AM (Pacific Standard Time, UTC-08:00)
I'm with Robert on this one and wrote a blog post with my point:

We definitely have room for removing accidental complexity, but software alone will never address inherent complexity. Business processes are full of inherent complexity (and more than their fair share of accidental complexity as well). How can Access or any tool address that? That takes systemic change in the organization through process improvement like those espoused by Lean.

Not only that, this only addresses building an app, but apps spend much more time in maintenance mode than development. Those things need to be addressed.
Tuesday, October 13, 2009 10:47:05 AM (Pacific Standard Time, UTC-08:00)
Agile principles are just like any other principles in software practice. Just by adopting agile does not make a software successful. It also depends on the type of the project you are working on. There are many small projects where applying agile principles will not make sense. Specially, when the project has a crazy deadline and small budget.

I have seen successful agile projects as well as successful water fall projects. So, anyone who says that the project failed because you did not applied agile is wrong. The reason the project failed was because lack of communication and lack of follow through of the practices applied.
Tuesday, October 13, 2009 10:53:50 AM (Pacific Standard Time, UTC-08:00)
I don't want access back. But I want an access like thing, that may gracefully evolve into a 'real' application.
Tuesday, October 13, 2009 11:24:43 AM (Pacific Standard Time, UTC-08:00)
Great post Ted...

Like Rod, I made a nice living and wrote a few books re; Fox. Fox was simple and complex at the same time. It was simple to the extent that you really did not need to "move out of the box." At the same time, it was complex enough to build sophisticated applications. The question oft asked to day is whether software development is "too complex" today? I am not sure where I am on the question. I can construct arguments that either answer that question affirmatively or negatively. If somebody wants to, he/she can easily build a windows desktop app ala VB 6/Visual FoxPro in .NET. With not too much effort, you can get such an app to look pretty close to a VB 6 style app - both in look and code.

But that is where the divide is...between the land of whether you can and the land of educational resources....

If Software Development appears to be more complex, then I suggest is has more to do with the messaging. Far too few concentrate on beginner topics. If you are new to .NET and you are coming from VB 6 and you search the web for resources, you are in for a frustrating time. You either cannot find what you are looking for or you find comments that denigrate classic windows forms applications.

I have been developing software for 20 years and have seen a lot of the new shiny toys come and go. Though it all, core principles have remained. The scholarship from Uncle Bob Martin, Martin Fowler, et al are timeless. Today, I am well into C#, nHibernate, ASP MVC, etc. Through it all, while many of the tools change, the I find myself still relying on the basic first principles. And I suspect I will be doing so for some time to come.

Whether "Agile" is treating the symptoms and not the disease, I suppose reasonable minds can differ. I am a total noob when it comes to Agile. However, reading Jame Shore's book and similar tomes by Bob Martin and Martin Fowler, I do believe that the principles embodied in Agile methodologies do have a positive effect on the "Disease"..whatever the disease happens to mean in this context. Of course, "Agile" and anything else can be reduced to a buzzword - reducing it to yet another meaningless phrase. Agile, like anything else, is not a panacea. In regards to Billy's comments that Agile demands certain things, I contend it does not. Agile is just that... I think you can apply some, none or all of it. Again, James Shore's book on Agile Development is a really good resource. Perhaps only some aspects of Agile are a good fit for your shop. Based on what Ted has written re: Billy's comments (and that is all I have to go on) - I don't think Billy does a good job of defending his Agile point. Again, I am an Agile noob...but I suspect that Billy really does not understand Agile - and his comments tend to reflect that. It reminds me of the DevLink panel (which Billy was a part of) and the panelists started to comment on Ruby. None of them had the experience to make those comments and Leon Gersing had the wherewithal to call them out on it.

Tools and techniques can be as complex or simple as you make them. It's the fiddler...not the fiddle.

Tuesday, October 13, 2009 11:34:30 AM (Pacific Standard Time, UTC-08:00)
It personally took me several years to get good at developing business applications in Visual FoxPro. I suspect the very talented people you list would tell you the same thing.

Technology is not the problem. I could build a good application in classic ASP with a Visual FoxPro back end, not because the technology is superior to the alternatives, but because I am experienced at understanding business needs and modeling them in software. Managing a card collection and managing a company's payroll are not related domains at all.

Why is five weeks of training as a minimum an unacceptable barrier to entry? Software is complex. There are ways to manage the complexity, but it can never be entirely eliminated.

Tuesday, October 13, 2009 12:38:44 PM (Pacific Standard Time, UTC-08:00)
Agile is not a silver bullet and it does not solve all software development industry problems. Agile is about people. It solves many problems in software development process. It addresses business-to-development team communication. It addresses collaboration in a single development team. It addresses organizational problems and constant improvements. It evangelizes simplicity, simplest tools and solutions that work in particular conditions. It changes people’s mindset.

Yes, there are horde of new technologies on the market. There are so many cool new programming languages, development platforms, MDA solutions and tools. We are climbing abstraction mountain, rising abstractions layers. How many people write pure C code these days? Do you remember Assembler? DSL is coming (it is already there!) and will add one more abstraction layer on top of OOP. What’s next? I don’t know. But agile movement will sustain with new technologies. These are orthogonal phenomena: Technology and People.
Tuesday, October 13, 2009 12:44:13 PM (Pacific Standard Time, UTC-08:00)
Perhaps something like Processing (, but geared more toward business users?
Jeff Sternal
Tuesday, October 13, 2009 4:57:24 PM (Pacific Standard Time, UTC-08:00)
After being in this industry for twenty years starting out doing embedded systems programming, it seems like we have slowly been increasing the level of abstraction at which we are building our systems. Yet we are still primarily developing our applications in the domain of software thingies. I think what we need is a higher layer of abstraction to work at which will probably be facilitiated by DSLs.
Tuesday, October 13, 2009 5:11:30 PM (Pacific Standard Time, UTC-08:00)
I've got a horrible feeling it looks like PHP. (And come to think of it - I had the same feeling about Access)
Tuesday, October 13, 2009 5:29:41 PM (Pacific Standard Time, UTC-08:00)
I know that this will get a sigh from a lot of ppl, but today's Access is _unquestionably_ SharePoint!
Tuesday, October 13, 2009 6:22:33 PM (Pacific Standard Time, UTC-08:00)
I understand the feeling but this sounds like the author is just swinging drunken and depressed punches at anyone or anything that happens to stray within arms reach.

Once he's finished throwing up behind the dumpsters and a bit of a rest away from the bright lights for a few minutes, he'll hopefully discover that the buffet tends to look a lot more appealing when not fresh from a grease lacquered visit to Joe's House of Lard and that life really isn't as bad in the morning sunlight as what it seemed whilst heaving painfully into a nearby gutter.

Just because the menu has expanded doesn't mean his favourite dishes have disappeared. They're still there.
Yes, a lot of people do seem to be going straight for those strange foreign looking pesto and rocket covered dishes but that doesn't mean he can't still sit down to a nice comforting dish of tuna casserole.

And, yes, there is indeed an interesting range of sauces on offer on the table in front of him such as "Agile" and "Framework X" but that doesn't mean he's required by law to drown his meal in all of them... or that anyone is seriously suggesting it's going to taste better with said mix.

Yes, perspective may be worth 80 IQ points (e.g. try doing calculus using Roman numerals) and there's a lot of people out there offering a lot of different ways to reduce complexity ("Hey look! I can describe the problem in a language I'm familiar with")... but all these solutions are for very specific types of complexity.

No one is selling a magic elixir of universal simplicity and it's very unlikely that they ever will... thus standing on the sidelines and whining about the lack of such things isn't likely to produce many positive results.

At the end of the day the only two agents in the universe that are driving the level of complexity are the problem and the person trying to solve it... and only one of them has ability to change the situation.

If the problem can be solved by dragging and dropping a control in Access or Visual Studio then so be it. If it can solved by 10 lines of GW BASIC then all the more to party about. And if the solution doesn't involve any of the popular buzzwords of the day then nobody is going to care because they'll be enjoying a life with one less problem in it.
Tuesday, October 13, 2009 8:10:37 PM (Pacific Standard Time, UTC-08:00)
"Where is this decade's Access?"

It's the CMS. Joomla, Sitefinity, etc. You can make very attractive sites quickly, easily and cheaply with CMS tools. Yeah, the industrial strength ones are 6 figures, but that will drop just like the cost did for databases and servers.

The real question is . . . how will IS departments justify keeping a team of developers making 80k or more instead of a smaller team of "analysts" making <50k + a CMS?
Wednesday, October 14, 2009 1:20:55 AM (Pacific Standard Time, UTC-08:00)
Im sorry but this sounds like the loser corner that got picked last at gym class. I have been using cutting edge technologies + agile for years, and yes, there are uninformed pm or lead devs that abuse and misuse these technologies/methodologies. I dare you to work in one of the streamlined teams that DO get it right just for a month. You will never turn back! It takes hard work to stay up to scratch with all the new techonologies, but just because you dont want to make that effort, dont diss the people that do!
Wednesday, October 14, 2009 8:19:47 AM (Pacific Standard Time, UTC-08:00)
Good post Ted. With all the new technology coming out, it *is* impossible to keep up. I know I can't. I'd love to keep things simple, but sometimes it all just gets out of hand.

Agile done wrong, is worse than not doing it at all. By "done wrong" I mean trying to follow every principle exactly, whether you need it all or not. The company I worked for until a month ago was/is like that. Agile, taken to the extreme, was not working and yet no one attempted to simplify the process. Oh, some of us complained that we needed to simplify, but it fell on deaf ears and those who had the authority to change things never did.
Bonnie Berent
Wednesday, October 14, 2009 4:59:42 PM (Pacific Standard Time, UTC-08:00)
I think this post has lots of thought provoking things to say about our trade. However, holding the Agile process up as the problem is really like missing an opportunity to go to the root of some of these problems.

And hey! I constructed my own ODBC messages ... and now use LINQ. And I like my life now. Anyone who misses FoxPro and classic ASP so much, I think you've plain forgotten how those days used to be.
Wednesday, October 14, 2009 6:57:03 PM (Pacific Standard Time, UTC-08:00)
Haven't seen so many Foxpro people mentioned in a sentence lately. Just a correction, Ken Levy did not do data (LOB apps) in foxpro, but he wrote great tools.

Agile and the development methodologies address capturing and delivering an application that meets some functional requirements in a specified schedule. The problem today that those applications must have a wide reach (web-based), infinitely scalable, extensible, support multiple languages, etc. Those capabilities were never supposed to be addressed by agile process.
Pablo Fung
Thursday, October 15, 2009 9:34:34 AM (Pacific Standard Time, UTC-08:00)
Having had a foot in both the Java space and the .NET space for the last decade, I think C# (or Java) + db4o is this decade's MS Access VBA. Magic the Gathering Card Management System = POCOs (or POJOs) and an OO DB -- forget the frameworks, the foundations, the OR/Ms, the relational databases, the impedance mismatches, the unit tests, the integration tests, the UML, the XML, the code generators, the database generators, the workarounds for the stateless nature of HTTP, the dependency injection containers, and the dude that wants everything to communicate via Web Services - just make the f'in app already.
Travis Heseman
Thursday, October 15, 2009 11:00:40 AM (Pacific Standard Time, UTC-08:00)
+1 to Udi and this post. These "easy" this time around doesn't come from Microsoft; it's coming from the open source community.

PHP is really easy, but it opens yourself up to tons of potentially awful, difficult to maintain code. Rails, on the other hand, is ready to go - out of the box - with separation of concerns, a super simple ORM, business object validation, and a great community that's eager to bring more people into the collective fold.
Monday, October 19, 2009 2:01:59 AM (Pacific Standard Time, UTC-08:00)
I observe that You have some validity in your arguments.
I feel that the pattern of your post is "complaining, criticizing, not providing alternatives, and waiting for heaven's sent solution".

my 5 cents, this is rather destructive than constructive.

Wednesday, October 21, 2009 7:55:31 PM (Pacific Standard Time, UTC-08:00)
Some guy
Thursday, October 29, 2009 5:06:36 PM (Pacific Standard Time, UTC-08:00)
Where is the current Access? I think it is being built, by some incredibly smart developers at eTecnologia ( They are porting VFP to .Net. The resulting assembly is CLI-compliant, a first-class .Net citizen, .Net 4.0 not required. .Net classes are instantiated, with properties, seamlessly within VFP code. Additionally, the language is being extended. Tables can be of virtually unlimited size (64-bit architecture). Opening SQL (or any backend) tables will be as easy as using the SQLUSE command, and will be updatable, able to have buffermode set, etc. Gone is the impedance mismatch (as you point out in another blog entry).

I work as the technology guy (software framework and tools) for a small development team (2 coders plus me) who have successfully delivered a large (550+ table) retail inventory management product. The reason the product is good is that the coders are domain experts. No programmers could have gotten right what they have in their bones, from 15 and 20 years of experience in the domain, respectively. There is another impedance mismatch in complex software development, between the unarticulated knowledge of the domain expert, and the practical impossibility of getting all that knowledge first articulated, and then programmed accurately into the software. When the domain expert is the programmer, that impedance mismatch goes away.

VFP, with its easy access to data and sensible OOP capabilities (that help the developer, rather than get in her way), plus of course the ability to work easily with the IDE, makes this possible. I asked for ASELOBJ() in Visual Studio 5 years ago, and know that the request was brought to the VSX team. I'm still waiting ... well, not for long, because the eTecnologia Developer Studio is built on SharpDevelop, and they will have it.

eTechnolgia is looking for a feature-complete beta I believe sometime in Q12010. Two of the 3 last big pieces are going in within the next month. It's an exciting time to be a VFP programmer.
Hank Fay
Monday, November 2, 2009 10:48:41 AM (Pacific Standard Time, UTC-08:00)
Perhaps it was a rhetorical question - "Or, perhaps, let me ask it this way: your 16-year-old wants to build a system to track the cards in his Magic deck. What language do you teach him?"

I'd teach them HyperCard -
Wednesday, November 11, 2009 9:17:27 AM (Pacific Standard Time, UTC-08:00)
One of the answers for long tail is "full-stack frameworks", as Rails have been showing to us.

PHP is simple because it is simple (duh!). We need powerful and complex plataforms made simple.

How? In Java platform, you can do Groovy and Grails. One of the best choices today.

PS.: We could think that Access was a "full-stack", so was .NET Framework years ago. Ain't nowadays because development is still evolving.
Wanderson Santos
Comments are closed.