I agree very much with what you are saying – thanks a lot for contributing such a well thought out comment. I would be thrilled if many of the people who use the “small app” argument actually went through the process you described.

I enjoyed reading the article. It has some interesting insight into the use of patterns in the small/large application development argument. However, it is a rather obvious knee-jerk-off-the-top-of-your-head emotional response to a conversation you were having with a colleague.

Afford me a moment to deconstruct your argument.

You first attempt to define what small application development is, or what deserves the enterprise moniker. The resulting definition is boiled down to developer’s inaccurate estimates, and some questions that you don’t really address except through some fear/doubt/uncertainty. (i.e. small lines of code = planes being kept in air = what if we crash and die because of these lines of code??!? OMG we need an enterprise app!! = FUD; now repeat for each additional question)

Second, you address, what you call, the “real issue”, and attempt to accomplish this by using a subtle ad hominem fallacy. You attack the “small application developer” (for lack of a better description), demonizing their approach by categorizing it as ignorance, or lack of knowledge or willingness to become more educated. With the “Moving on…” conclusion, I have to wonder if you even really gave an thought to what the “real issue” is???

Third, you pigeon hole the whole argument into a single determining factor of the business lifecycle of the application in question. You don’t consider any other common factors, and you don’t explain why those factors should or should not be used.

Finally, in your conclusion, you dismiss the argument (which isn’t addressing it at all), by saying you can’t have a intelligent conversation about small application development because you shouldn’t use psychology. You do however bring up scripts, which gives the audience an interesting insight into why you are against so-called “small-application” development – QUALITY.

If we equate small-application-development (SAD lol) to POOR QUALITY then you are correct, there is no way to approach a conversation about this issue using psychology. However, if we REALLY look at what small-application-development is and truly come up with a good definition, then we might be able to avoid the presumption that SAD = POOR QUALITY.

Small or large application is still the process of app development, and still has methods associated with it. All application development is problem solving that uses a mix of form and function, art and logic. If you allow the analogy, we can conclude this just by the accepted standard of what we perceive as “smelly-code” (form/art), and “SOLID” code (function/logic). As an artist & philosopher, you are restrained by what the business world wants…and that means PROJECT MANAGEMENT!!

Any project manager will tell you there are three constrains on projects Time, Cost & Quality. When we view how we develop code within the microcosm of the business world we are stuck within this project triangle. We therefore have to develop applications that meet the business requirements while staying within these drivers.

From a business perspective, a developer MUST ask three questions:
1. How much time will it take to develop/implement/deploy/maintain this application? (this is your argument’s assertion that we should only be concerned about)
2. What is the COST of the methods I can used to develop this solution? (monetary/non-monetary/opportunity costs)
3. What kind of quality does the business require?

From a developing perspective (and this is not a comprehensive list) there are questions that should be asked (which blend with the business questions most commonly the cost consideration), for instance:

1. What is my level of understanding/knowledge of the proposed method of development?
2. What will I need to learn before developing this solution?
3. How much time will it take for me/team to develop this solution?

So long as we assume “small” application development or pattern-lite style programming is equal to poor quality applications we won’t be able to create a healthier development stage for what we all ultimately want to do….solve problems. If we take the opportunity to truly define appropriate use of patterns on an enterprise level and on a one-off, small, pattern-lite or script style programming we move closer to a more unified developer community. There is an interesting assertion that more often than not, the less educated developers are the ones developing “small”, pattern-lite, & smelly code. This is true in some cases, however, it is up to those with more experience not to alienate or pontificate, but to collaborate…

There are ways to leverage small/pattern-lite applications – ones that are maintainable – and still deploy quality software…an artist knows when less paint makes the painting more….

When SOA is done properly, services are logical and not necessarily physical. Multiple services can be on the same box, or even in the same process. As such, it fits just fine with Fowler’s recommendations.

Happy to hear you’re enjoying NServiceBus.

By the way, I’m introducing NServiceBus to my newest project. And it’s cool

Take care!

We need to understand the position of the people we’re talking to, and learn to bring our message to them in ways that will be easier for them to swallow. Doing a small prototype that they can look at; refactoring one small part of the system to the new pattern; giving them access to reference materials and training – organizational change isn’t easy.

Indeed – resume-driven development should not set the tone of a project.

As long as the context is actually considered, and the pros & cons of the given pattern are weighed, if the answer is not to use the pattern, that’s fine. My concern is that patterns are dismissed without being really considered.

If small, compact, and changeable addresses the requirements, super.

Thanks for your comments.

Real-time data just has tighter staleness requirements – under 5 seconds, under 1 second, under 50 microseconds for high-frequency trading.

Reading through your blog post, I didn’t see you addressing the trade-offs between how often some thing happens versus the cost of preventing/ensuring it happens 100% of the time.

The question/thinking processes that I describe are the important parts of the process, not the answers that I use to demonstrate them.

Thanks for your comments.

I can agree that the name CustomerMoved sounds more like an event than a command, and does not capture the context of *who* is doing it – which matters to whether the command is accepted or not.

Naming is hard, as it drives to the heart of business modeling.

Thanks for your comments.

I’ve seen this used time and time again, and it almost always has been someone that was simply fearful of change. In some cases, it driven from needing to invest some extra time to learn a new approach. In other cases, it is provoked by the reality that the person doesn’t really have the technical capacity to comprehend what is involved. There are also instances based on political reasons, but those also ultimately tend to be based on fear of something.

Regardless of the reason, the “small app argument” and other variations often seem to be motivated by fear, and it is amazing [sad] how many poor technical decisions are based on fear.

http://www.softec.org/blogs/central_coast_code/archive/2010/03/09/beware-stale-data.aspx

Thanks again for your time in putting together presentations like this for us to watch.

I think I phrased my question wrong, I knew what has to happen on the technical side, i. e. send something that contains the userid and the product id.

I think I just don’t like the phrase command in this case as it is not really a command, all other command are more like MoveCustomerCommand and not CustomerMovedCommand.

Anyways I think I’ll just accept some “badly named” commands to keep things simple.

Thanks again.

I hear you. I ran into that with Ayende’s presentation as well. Will check with Skills Matter.

Vukoje, I agree that some teams aren’t experienced enough to apply more advanced patterns. And while staying in their comfort zone won’t burn down the project in the short term, it will likely undo the business benefits of that project in the long term. Wouldn’t the business want to know about these impending problems? Maybe failing fast is better? It depends