I'll get to your application in a minute - First, we need to build the framework

Today at lunch, I had a conversation with Kevin Hurwitz about developer tendencies.  Kevin related a project he consulted on.  He came in after over a million dollars had already been spent by the client, and he found the following:

  • Not a single feature had been delivered (save a few half-finished screens)
  • The team had spent all the time creating an application framework that, when finished, would make the application practically create itself.
  • The development manager was the one who instigated the framework frenzy, and was eventually fired.


Clients typically engage us for actual software.  A client isn't interested in software that can be used to create software (frameworks).  They have a problem, and a software system can help them solve the problem. 

I, along with Kevin, have encountered the common mindset of falling from application mode into framework mode.  I find it's common with really smart programmers who take pride in their technical ability.  Creating frameworks is fun because the programmer is the customer of the framework.  Writing software for yourself can be more fun than writing software for someone else.  Writing a framework is writing software for yourself.  On a client's dime, this is typically not acceptable. 

The customer needs to see the software come to life before his eyes.  Every week, the customer need to see new features working. 

Playing devil's advocate:  _If_ it were possible to create the magic framework that would make the application practically write itself, communication is key, and it's a bet, a strategy, an approach.  If this were possible, and you'd successfully done it time and time again for many clients, then it should be discussed with the client beforehand.  Ultimately, the framework becomes property of the paying client, so the client ought to know what is happening, and the client needs to be ok with it.

Back to reality:  Frameworks are better harvested from several applications that ended up using similar patterns.  Writing a framework before an application is BDUF (big design up front).  There are so many assumptions that go into the framework that some of them are bound to be wrong.

The real, repeatable satisfaction.  With many programmers preferring framework development, a client-centered process can bring joy in working on the client's application.  Delivering new builds of the software frequently will please the client, and that level of customer service brings satisfaction back the other way.  There is nothing better than an elated client who loves what he sees unfolding before him.

What about all the common junk that the application needs?  Chances are that there are already libraries that satisfy your needs.  Data access. logging, authentication, caching, indexing, builds, UI controls, etc.  There are both commercial and open-source offerings that make great buy vs. build decisions.  For the needs that don't have offerings yet, do it first, then when the exact same need comes up again, it will be easy to create a library that satisfies this common need now that you know _exactly_ what the need is.  Then, the library or framework can be created _without assumptions_ because you have experience to back up the uses.

For more, you can subscribe to my feed:  http://feeds.jeffreypalermo.com/jeffreypalermo


FuzzLinks.com » I’ll get to your application in a minute - First, we need to build the framework Posted on 7.14.2008 at 4:07 AM

Pingback from FuzzLinks.com » I’ll get to your application in a minute - First, we need to build the framework

More on Silver Bullets - Sodaware Posted on 8.06.2008 at 2:57 AM

Pingback from More on Silver Bullets - Sodaware

Lazy Initialization :: Your Framework, Probably Won’t Posted on 8.14.2008 at 7:35 PM

Pingback from Lazy Initialization :: Your Framework, Probably Won’t

Delaying Decisions Posted on 9.13.2008 at 2:30 PM

I've recently finished reading Mary and Tom Poppendieck's Lean Software Development title, which

Delaying Decisions Posted on 9.13.2008 at 8:58 PM

I've recently finished reading Mary and Tom Poppendieck's Lean Software Development title, which

Paul M. Jones » Blog Archive » … But Some Suck Less Than Others Posted on 10.23.2008 at 8:45 AM

Pingback from Paul M. Jones » Blog Archive » … But Some Suck Less Than Others


Jason Olson said on 7.12.2008 at 1:54 PM

I definitely agree with this one! I think there is another problem that developers fall back on though. I've also seen many situations where a very simple application was needed (operating on just one entity, and not even full CRUD functionality, more just R). And the first thing the deveoper does is run out and grab Spring.net/NHibernate/Memcached/etc. This is in a TDD shop, as well. Extremely over-engineered.

I just find it kind of funny when the developer goes to write that first test and says "oh wait, I need to go out create my config, database, everything first". Kind of defeats the whole purpose of "You Ain't Gonna Need It". There are simply times when the tools above are overkill. Of course, 90% of the time, they are pure gold :).

Mauro said on 7.12.2008 at 5:32 PM

In my opinion and experiences that is not complitly true.

I think it's depend on clients and depends which work is required.

Sometimes spend more times to build a framework could be save the life to the project for the future.

I agree that the client want to see stuff, but we are not sell smoke if we think, based on analysis, that a client will have a benefits from a framework is our duty explain the prons and cons.

jpalermo said on 7.13.2008 at 1:08 AM


I'm always open to the possibility of being wrong. I just haven't see that, when asked to develop a line of business application, building an application framework first make the application really easy to write.

Please point me to some research or experience reports to the contrary.

AvaSys.Healy said on 7.13.2008 at 6:15 PM

Ah, the oft heard and very agile: "we don't need no stinking framework" tout. I typically rank this one up there with "we don't need no education..." - to which a sardonic colleague once replied, "yeah, give us disease instead!" Now, this claim might be true of small, independent, and restful apps which basically present a bunch of static information, but for anything transactional of significant scale and built on a hierarchy of services, then I'd say you'll likely be getting ninety percent of the way through the project with a 'found' architecture, a 'found' performance, and a 'found' nightmare for installation, integration, and administration.

The tend from the beginning of agile proponents disparaging framewarks of any kind was as extreme as many ideas in the CMM/CMMI world at the opposite end of the spectrum. And the first thing the more vocal and successful agile advocates I know did and do on a project is whip out a framework they've built over time for everyone to use - they just fail to call it a "framework". And while I understand the utility of this claim to get folks' heads out of the sand in the beginning days of agile, looking forward to cloud-based apps and services of the future it's now time to use this claim with more balance and perspective understanding "frameworks" and "platforms" are a very necessary, and in fact desirable, aspect of computing from here on out - which is why all the vendors and major web players are working feverishly on theirs. I personally say more power to them, the less code I have to write the better.

Steve Smith said on 7.13.2008 at 10:08 PM


I don't think Jeffrey is suggesting that no framework be used - I just think he's drawing a distinction about what your team that is engaged in developing an application for a customer should be building. Should your team build a framework that any team could use to create an application like the customer wants? Or should they focus on building said application, and pull in whatever things they need from the customer's own libraries, the consultants' past tools, open source and/or commercial libraries, and even the platform framework. Why rewrite logging when there are a dozen different free logging tools? That's what he's saying.

Tim12s said on 7.14.2008 at 3:58 AM

An appalling scenario that may occur is that unless the framework developers are kings at foresight they make things more difficult for themselves in the long-run. When the business requirements change in 6 months time (business always evolves) the framework would typically have to be changed to support new requirements and becomes a burden.

My suggestion is that there are plenty of frameworks out there. Choose a couple; get everyone to understand how to use them effectively and then get the job done. 3 years ago we did not have much of a choice because maturity of frameworks were questionable due to bugs and features. Today the landscape is completely different. There is alot of quality stuff out there that, with good good programming practices and good design, will make your life easier.

Jim said on 7.14.2008 at 4:14 AM

*Cough* Mozilla *Cough*

AvaSys.Healy said on 7.14.2008 at 5:52 AM

My point was that the roots of this old [agile] argument hails back to a time when few if any decent frameworks existed and the idea behind the argument was essentially that folks should be writing everything from scratch and not building a 'framework' they could employ again and again.

The reality was and is even hardened agile advocates all employed a pet collection of 'tools', and most integrated them into a 'framework' they could use again and again even if they didn't call it that. And for a long time those frameworks have been for simple things like persistence (settled that one didn't we...), logging, etc. and today there are many able 'frameworks' for these basic application requirements.

However, moving on to SOA, SaaS, cloud-based apps, and apps delivered as suites of related services (social networking + ecomm) then you bump up into a higher level and sphere of concerns where 'frameworks' aren't optional, or evil - and what do we do between now and when MS Oslo, or a public release SalesForce / Google / Amazon / Oracle / xxxxx burly new framework? The problems these frameworks will confront are way more complex than mere persistence or logging - the just released Configuration Service 2.0 is merely a single building block of a very necessary comprehensive services management 'framework'. Again, what to do until vendors or open source delivers these kind frameworks? You roll your own out of the various available components and fill in the blank with your own code to assemble your own evil 'framework'.

The whole of the Alt.NET world is about folks writing and assembling 'frameworks' - NServiceBus and Mass Transit are perfect examples of this. These frameworks are developed, deployed, and enhanced on someone's dime, and I suspect more than few clients have picked up their fair share of the tab along the way if a real tally could be made. That, and Oslo, google's App Engine and Android, Salesforce's 'force.com', Amazon EC2, and Facebook Platform all validate the value and efficacy of a well-designed framework or platform in app / service development. If one isn't available for the scale and scope of work or complexity your application[s] require then the only intelligent option is to get busy developing it - unless it is a one-off and noone is concerned about reuse or leveraging the investment.

chris neglia said on 7.14.2008 at 6:11 AM

in my experience, this is true, for simple applications. i think clients need to know up-front that additional features they wish to add later can add exponentially to the cost of development without a framework. You see, technical people are prone to making assumptions based on their experience, and they pretty much know how a project is going to play out (this is reinforced by non-tech people saying ignorant things like 'my internets', 'dekstop', etc.. revealing how little they actually know). Proper coding takes time and tools are great, so it's actually easier to use an open source project and 'disable' or 'turn off' unnecessary features. That way you get to satisfy the client quickly by configuring and customizing versus custom coding, and if need be, you can add activate and add while reaping the benefits of the frameworks offerings and (in some cases) a plugin architecture.

Chuck said on 7.14.2008 at 6:54 AM

Simply stunning insight ....or it would have been if this was 1991 and several million other people hadn't already made this observation. Instead it's just pollution.

Jeff Santini said on 7.14.2008 at 7:10 AM

Re: AvaSys.Healy said

The blog posts says the devs were working on a framework and not a single feature had been delivered after $1,000,000. Is this what you are advocating? He also suggests using existing frameworks, and extracting common functionality or writing frameworks AFTER you have seen the need in a few projects. So by these practices it seems to me all the positives you talk about will and do come into being. So the big point of the post is don't write frameworks INSTEAD of applications on the clients time. I don't understand your criticism unless you disagree with the above statement.

Henrik said on 7.14.2008 at 7:11 AM

The goal of frameworks is not to have an application write itself. They simply generalize a problem and package it into a reusable piece of code.

Building a general solution to a specific problem that isn't likely to change is usually a waste of time. However, so is spending time using/learning an existing framework that does not fully satisfy your needs. But then, so is custom building solutions to problems that have already been solved, especially if there are security and stability considerations, like a persistence framework for example.

So I guess like all development, the correct answer is "it depends".

jpalermo said on 7.14.2008 at 7:52 AM


Your points are mostly valid, and I find I agree with you, but I don't see how my post contradicts to your thoughts.

Although I didn't mention Agile in this post, I don't know anyone (myself included) who thinks Agile means writing everything from scratch. I coach my teams to write as little as possible, and that means leveraging tools and libraries already available in the marketplace.

jpalermo said on 7.14.2008 at 7:53 AM


I agree with you that this is not a new thought. I, as well, thought it was fairly well-accepted, but I still see it popping up. I think from the comments, the industry still might be diversified on this topic.

Jeo said on 7.14.2008 at 8:47 AM

These guys went way overboard, but sometimes the ground rules are different. Where I work, the clients only own the data, we own the code. That makes it a lot more important to build reusable code that we can resell for new projects.

Unfortunately we tend to have the opposite problem: doing the same old thing over and over again. I generally manage to spend a little extra time up front and reap the benefits later, but it's not the general practice.

Wolter said on 7.14.2008 at 9:45 AM

Pretty much spot on.

There are exceptions, but you'd better be experienced enough to know the difference before throwing yourself into an over-engineered product.

Frameworks are to be written ONLY when you have extensive experience in the domain you are writing for. Only then can you have any possibility of writing something that's actually going to help rather than hinder you, and only then can you estimate the time required to build it and decide if it's even worthwhile.

If you don't know the domain well, do some research. Chances are there are tools out there designed to deal with the issues you're facing.

And if you DO know the domain well, do some research anyway. Someone might have written exactly what you're looking for within the past few months.

And when you're not writing this stuff, do some research into new tools & technologies, and play around with them in some dinky programs. You'll never know what's applicable if you don't know what's out there and how it's used.

Wolter said on 7.14.2008 at 9:45 AM

Pretty much spot on.

There are exceptions, but you'd better be experienced enough to know the difference before throwing yourself into an over-engineered product.

Frameworks are to be written ONLY when you have extensive experience in the domain you are writing for. Only then can you have any possibility of writing something that's actually going to help rather than hinder you, and only then can you estimate the time required to build it and decide if it's even worthwhile.

If you don't know the domain well, do some research. Chances are there are tools out there designed to deal with the issues you're facing.

And if you DO know the domain well, do some research anyway. Someone might have written exactly what you're looking for within the past few months.

And when you're not writing this stuff, do some research into new tools & technologies, and play around with them in some dinky programs. You'll never know what's applicable if you don't know what's out there and how it's used.

AvaSys.Healy said on 7.14.2008 at 9:59 AM

Jeff, sorry a little sensitive on the subject as this "don't write frameworks" argument was always part of the steady agile drumbeat from the beginning, though not explicitly included in the manifesto, back when if you wanted the utility of any form of framework, you had to write it yourself against a lot of dogmatic flak and resistance. Your comments and mine align for basic needs today, but we are still screwing around with persistence and logging frameworks at a time when more pressing and complex "framework" priorities are upon us in order to make the leap to SAO, SaaS, Cloud services, Social Networking, BPEL / WS-CDL. The whole EF debate also gets me riled up in this context as we've been screwing around with persistence forever when we really need to clear that plate once and for all and move on to other priorities barreling down the track at us. I've always been a fan of agile - except this particular aspect of it which has always struck me as unnecessary dogma.

Artur said on 7.14.2008 at 10:47 AM

Yes, it feels like never ending nightmare. Time and time again programmers praise their designs for allowing unlimited extandability, reusability, and blah blah blah.... At the same time as implementing just another way of expressing super specific solutions, that are simple beyong dispute only due their utter stupidity and uselessness.

Another thing that haunts me the most, is that OO-people always seem to know the way "how it Should be done". At the same time as having no personal tools or source codes from their previous projects to reuse.

And one more point. As many know it's really insightfull to talk to artists and other non-technical people about program requirements. Their uncomplicated ideas and questions help you "restart" your thinking process, and re-examine the problem from additional angles, helping the brain exit from that narrowminded answer seeking mode. In that respect designers and architects are like testers. Their dayjob consist of re-evaluating previously made decisions over and over again, and asking stupid questinions like "why can't all our problems be solved with a single button 'solve'?". This is extremely usefull collaboration work, especially because person solving the problem has no energy left to think about these questions after 12 hour long days. But what bugs me the most, is that these "testers" get to make all the decisions about systems they understand only in caricaturic form, and who in the end receive the biggest salaries.

Kevin said on 7.14.2008 at 11:53 AM


Because the software industry only needs to be told something once and it's fixed forever, amirite?

Travis Van said on 7.14.2008 at 12:40 PM

I think the "business person" can often affect this outcome by not knowing precisely what they want the software and features to look like. The developer tries to force more specific input about feature sets and performance, requesting very exact use cases / actors / prioritization of features / et al. But the business person continues to give somewhat nebulous feature set definitions, while really emphasizing the grander scale opportunity they are pursuing or problem they are trying to solve. The developer can thus get lured into creating a platform / system that gives enough FLEXIBILITY to address the widest range of possible features that wishy-washy business person *might* want. If the client's input is ambiguous, so becomes the platform.

But I also agree with Arthur about how annoying it is that folks that portray themselves as experts in a field can talk the necessary game to win the business, but don't have any specific tools to bear or code to re-use. That's sort of like sales folks that talk big about their "relationships" in an industry to get the VP of sales job ... then after hired, immediately start bitching about a lack of leads (huh? if you have all these connections, shouldn't you hit the ground running?). I think that's one of the big reasons why so many vendors today weigh open source contribution as a major factor in evaluating potential new development hires. IMO, that's tangible proof that this person doesn't just talk conceptually about how smart they are with a technology or problem domain - they actually spend their own personal time coding / contributing / etc.

casey said on 7.14.2008 at 12:45 PM

Writing frameworks are fine, as long as they either take a very short time to develop (a couple days or less, for example), or otherwise emerge naturally from cyclical refactoring.

I completely agree that big framework design up front is a bad idea and likely a one-way ticket to meta-meta-land. However, developing without an eye out for continuous refactoring into an emergent framework will eventually lead to a big dead end, followed by a big rewrite of brittle, repetitious (and potentially copied-and-pasted) code.

AvaSys.Healy said on 7.14.2008 at 1:11 PM

I'd say one has to distinguish between domain-specific frameworks and those generic ones like persistence, logging, etc. I agree charging into domain-specific app frameworks is by and large a mistake. But I challenge anyone to come up with a SaaS, social networking, or SOA management framework in a couple of days - let alone crib together an 'emergent' one. Now you can say "then don't do the app until one exists", but time marches on and deliverables happen - I'm not prepared to wait until 2011 for some of these to materialize and neither are a lot of other folks. The sort of frameworks I'm talking about are more on par with the scale of NServiceBus which assemble many existing smaller scale frameworks, fills in the blanks, and provides substantial [generic] functionality difficult to do without in an app / domain that requires such capabilities. Open Source contributions count big, but somewhere clients are footing a substantial part of the costs one way or another.

Raymond Chandler III said on 7.14.2008 at 4:56 PM

Let me ask you a question. Did you scrap the framework entirely or use some, if not all of the code? If you didn't try to salvage the project then you sir, are a horrible consultant.

I have seen, on many occasions, frameworks saving a lot of headaches in the long run, and reducing overall development time.

I do agree that things can be over-frameworked. But this is due to poor project management and the introduction of non-features that the customer has not requested, than due to the nature of frameworks.

It all comes down to the right tool for the job. A simple application rarely requires a framework of any sort, but large projects that may turn into ongoing enterprise software often benefit from these systems.

It is never a good idea to make a broad, sweeping, generalization.

jpalermo said on 7.14.2008 at 6:41 PM


This wasn't my company's project. I heard about this situation from a friend. I'm not sure if the framework was scrapped.

Yohannes Kristiawan said on 7.14.2008 at 10:40 PM

I start to build my first framework many years ago. Since then, I modify it so many times. Few things I learn:

1. The first few versions are simply bad ones, after many iterations my frameworks is good enough as 'production quality'.

2. I think we have to focus on what the framework can do (aka. having clear scope about what it can & can't do). Otherwise, we only increase the unecessary complexities.

3. It is hard to develop a flexible frameworks, I reach a certain of comfortable flexibilies after many iterations.

4. Server side or client side heavy processes? My first aproach is server side heavy, but in the end I choose client side heavy. In developing web-based application, the client is always javascript, while the server part tend to be changed more frequent (COM+ to NET, etc.).

5. Database agnostic aproach: I stick with SQL ANSI 92 commands only. Now my framework can seamlessly support MS-SQL and Oracle. Other database support can be easily added.

My conclusion: build your own framework only if you are going to be in the business for a very long time because it will cost you so many long-long hours and so many headache. But when you finish it, you will enjoy your hard work.

Jon Hancock said on 7.15.2008 at 3:02 AM

I wrote many frameworks in the 90s. It all started very innocent but they grew in breadth and depth. In those days, it was easy to justify as there were no commercial or open source options.

Now there are so many F/OSS options that you do really need to justify rolling your own.

Not all framework are created equal ;). I'm quite the snob and find very few I will use out of hundreds of choices. It is a good idea to write your own simply so you can be an expert at choosing others.

Damon Wilder Carr said on 7.16.2008 at 1:55 AM

I would like to offer the exact oposite and equally devastating problem I believe I now see about as often.

Recently I had the most astoundly bad experience on a large and very 'mission critical' so I was told project.

Not only was the entire team (self-desribed gurus) shocked and dismayed if I even uttered a 'design pattern' word (day 1 hour1 this happened and I didn;t even realize there were places you couldn't do this.),

They treated my explanation of 'patterns are really about higher bandwith team communication, not highly complex and mysterious concepts'. Nothing. Nada.

Strange yes but OK I am used to people freaking out on items like that on occassion so I simply reverted to the 'long version' sketching the UML each time hoping my purpose was clear. No dice.

'Any attempt met with 'this is fine in your ivory tower but we have code'. Mind you they had not one 'layer' in place properly (in terms of service layers) and it was a disasterous tangle of dependency house of cards waiting to be knocked down.

So I submit an anti-pattern for Organizational Culture called : If it's not code is BS.

Now for the best teams they CAN succeed here. There are almost no 'best teams' around by definition and I won't go into their trappings (but will trade for those any day).

I also submit the culture allowing this disasterous set of beliefs to exist cannot be driven by any strategic imperitives, oversigth that matters on 'doing the best job reasonable', or to be strive for average performance. THEY JUST DON"T CARE as jey, it's a cost center, not a strategic empowerment.

I watched in shock as these guys hapily dismantled any chance of success (in my opinion) until I had to draw my line in the sand. The weirdest thing is I was hired to 'resolve their lack of an architecture'!

As often happens when the personal pain is understood (you mean I might have to read!) everything changes and your a snake oil salesman no matter how many books, expereinces, or immutable facts you present, no matter what you personally have accomplihed. It's faith vs. science and that is stalemate.

I finally decided that if they refused to even consider or offer an alternative for a seperation of view/web concers from their 'controller/presenter' concerns (which for this app was a slightly more complex 'wizard-driven' ajax app with tremendous reuse potential that in the end they threw away for copy and paste.

So,,,My point? The only safe thing you can often say: Things in this world are complicated, no assumptions can be made on any assumption of 'it's the right thing so of course it will happen', and often human factors driven by pure self-interest drive software.


Kind Regards,

Damon Wilder Carr, CTO



Damon Carr said on 7.16.2008 at 2:02 AM

Also, for those stating Agile is not about Framework considerations or design that is just 1,000% wrong. As a guy doing it from almost day 1, Agile is about understanding and letting go of what you cannot possible to well at that point in time.

People want to tie so much negative spin on Agile. IT IS JUST COMMON SENSE. Dont think you can spec a complex system before you start. It's about people and interactions. Tools are critical but not THE MOST critical thing. And no effort of reasonable complexity would be described by an Agile advocate as not requiring 'precisely the framework decisions you can make at that time, but no more'. Defer defer defer decisions but damn well make them when you need to. None of this is new or even my ideas. Just read the literature.



AvaSys.Healy said on 7.16.2008 at 4:26 AM

Well, as someone else involved from day one, I can assure you architecture and design were very much [relentlessly] pitched out with the bath water.I will grant you architecture more so than design, which was still done, but more on an individual by individual basis. 'Found' architectures and performance is my ownly complaint with 'old school' / 'pure' agile - otherwise I'm a fan. I ascribe more to the same hybrid school Juval Lowy typically describes:


Damon carr said on 7.16.2008 at 8:18 AM

I respect your comments. I know Juval.. He is an amazing mind. Thanks for the insightful response.

On your first point:

The key question is not if it was thrown out or not. OF COURSE it was as in those days they style was 'predictive' more then not, as in macro-comprehensive entity models for example where you had not even begin to iterate/learn.

My key question to you is 'did too much get thrown out and had that hurt Agile today'.

I would say it worked for reasons I cover in a sec. And Agile for me is useless as a word now as the industry has destroyed it like the others.

I use the even more annoying 'post-agile'. I'm looking for a word here. People who kow better will assume your an idiot and people who would care typically are idiots. So what (if anything) do we call this moment in time for the Agile world?

And when I say day 1, of course I wasn't at Crysler (grin)... For me that is just commiting to say XP and having everyone say your nuts/an idiot (grin)...

Here is the semantic problem:

1) By definition you must 'pitch out' any decisions you are not forced to make at that moment as of course the longer you defer the less likely you must reboot

2) This to me is just common sense, not agile, and I think the Poppendiecks made this far more rigourous and explicit in their work. I find it extremely helpful to try to get people to NOT add people. NOT try to manage to a schedule. ALLOW themselves to say it's ok they are learning and it is not a lack of control.

2) On the individual by individual basis I can see this other dimension and I would offer this: Early agile teams were almost universally the best teams around.

Therefore you could trust your peers to 'do the right thing'.

To me Agile is like the Libratarian party. If everyone were really on the ball it would be a no-brainer.

The only pause is the vast majority (some say 80% and that sounds right to me) don't care about writing blog posts on software (grin).

si said on 7.17.2008 at 1:17 AM

Ahem...guilty as charged!

Caveat: We do have a working product.

Would love to forward this to my managers, but *cough* that last bullet point might hurt ;-)

Kiet Ly said on 7.17.2008 at 9:17 AM

Develop framework make sense if % of reuse is high in the organization. Develop framework should be a team on its own and separate from application development team.

Artur said on 7.17.2008 at 12:17 PM

'Si', nice job making the working program! It's of course only a minority opinion and I don't have any facts, but for me it actually sounds like you have some smart people working there. People not afraid of making their hands dirty with serious implementation tasks. Btw, were "ivory tower"-metaphor your invention? :)

Damon Wilder Carr said on 7.18.2008 at 8:32 AM


Guily? I hope I didn't appear to be finding fault. My comments were in no way directed towards you.

I'm speaking to the 'average dev with 2.6 kids' on the average team that misses all metrics 100% of the time (grin)..


Ha ha.. I'm pretty sure your answer was more to me then Si? I hope it was as it was brilliant. It seems you also though I was going at Si?

Consider where I live as an environment factor.....

No assumption exists for good software like Si's. I'm from the Silicon Vally region and that defines me but I work in New York City where IT basically gets you a seat at the big-boy table but not much else but 'keep the septic tank runnin' bob we don't want another backup' (of COURSE many exceptions exists but again, this is the average from everyone doing this work here at a decent level

It's not even debated anymore. I'm stupid because I actually try to change it as for some reason I used to think people would want to know about 1000% losses (wrong word as no gain was ever expected as on the books these are ledgered as operating overhead more then not, and were never even considered as you would a 'profit line'.

This is not speculation. This is the expectation of me and many others in regions that have large economies and no real drivers to software culture.

Finally, indeed I invented the Ivory Tower and you owe me 2 cents for your use of it.

The original is here with me. I make sure I haul it every day polished anew and it sits proudly on my desk so nobody will even think to ask me for a real deliverable. (grin). Actually you could not pick me out from any group of developers which I know you don't believe...

Anyway, thanks for steering me towards the light.


Brett Baggott said on 7.18.2008 at 11:04 AM

With apologies to Chuck, I needed to hear this. Thanks. Chuck's probably right and it's just my fault I haven't come across the other million posts from 1991, but still. Another issue I see related to frameworks is that, rather than approach a situation unbiased, many consultants will try to solve a problem using _only_ their framework they've developed over time. Sort of the "if all you have is a hammer" situation. For me, I find YAGNI very helpful to remember in this regard.

Olivier DALET said on 7.22.2008 at 3:55 PM

Agree with you: and I'm neither a client nor a manager; I'm a software developer: what I love most is ... writing frameworks.

More seriously, you have to admit, that the point is not either black or white. A pinch of reusability and a salt of design can't be bad (call it a framework or not) among vast parts of monkey code. It's just a matter of proportions.

Francis Shanahan said on 8.07.2008 at 9:02 AM

"Give a man a fish, he'll eat for a day.

Teach a man to fish and he'll eat for life.

Give a man a Fishing Framework and he might starve to death before choosing the most elegant, re-usable way to bait the hook."

- Shanahan 2008

More thoughts here... francisshanahan.com/.../detail.aspx