So, we put on our senior engineer hat and plow to the front of our geek kingdom, asserting that we must develop significant long-term infrastructure in the system because it will save the company thousands, if not millions, of dollars down the road.  The infrastructure is not needed to satisfy the agreed upon use cases for this release, but it’s so important that the team would be crazy to omit the work we are proposing from this iteration.  We are so convinced of our own superior planning and genius, that we are unconcerned if no one has recognized how much pain we are saving them from yet, or that it has put the project behind schedule.  They will see some day…

Throughout the industry services are often closely identified with Service Oriented Architecture (SOA).  There is a wealth of quality architectural thinking within the SOA world.  However, there are some fundamental issues that have propagated throughout large parts of the software development industry because of the underlying philosophies found in SOA.

A central theme of the SOA development paradigm is the focus on reuse.  Software developers with even the shoddiest training have been taught to place enormous importance on reuse, where logic is modularized in a single place and used over-and-over.  So, there is nothing unusual about the SOA assertion that services should be loosely coupled and designed to support numerous clients.

A major challenge is that services in a Service Oriented architecture must also be built to support clients that have not yet been formally defined through a requirements process, or even yet conceived.  In seemingly countless instances, this has led to teams completely over emphasizing the reuse of the services being built, while immediate functional requirements are often missed, not completely supported, or in the worst cases blatantly ignored.

Pragmatic software architects recognize the considerable pain the industry has experienced from projects that over-accentuate one software tenet (reuse), while ignoring others.  Overly generic services frequently lead to extended development schedules, and in some cases they are fatal to the entire project. The blame for this trend is not SOA itself of course, but software engineers taking a good concept and overusing it until it becomes a liability.

There are absolutely cases where reuse is the chief priority for the service implementers.  A common example is creating a true, public API, such as a travel booking service developing integration endpoints for their present or future partners.  Or, for an internal IT example, consider the case where the system holding the source of customer records needs to expose the data to multiple systems throughout the organization, and a reusable service is required.  These cases are limited though.  In particular, they are most rare in IT shops, where the insanity of completely over-emphasizing reuse can be at its highest.

Quality architects avoid this trap by working with the following understanding:

• Risks should be identified.
• The business domain should be captured through the requirements process and implemented in its own layer.
• The implementation should only include things that address specific project risks that have been identified or satisfy the functional requirements of the system.

Thus, the system should be built for the immediate needs, unless there is a priority placed on the future in the business requirements, or the project’s owners specifically dictate this as a priority.

Reality check: It is not your money! Building a software system should be focused on the urgent needs of the organization, unless the team is clearly directed to focus on other priorities, which is rare.

Check out the episode here: http://www.drunkonsoftware.com/2009/04/05/episode-11-matt-raible/

Enterprise software is almost uniformly horrible, but there’s no reason for that. We’re seeing a “UX revolution” in RIA design, and for all the buzzword nonsense surrounding “user experience, ” there’s something real happening in terms of the overall quality of the experience delivered by RIAs. We’ve seen some really great and innovative work in consumer RIAs, with a trend toward simple and intuitive interfaces. And yet in enterprise software this trend has barely even begun, it’s all still complex. I want to see enterprise applications treated like consumer apps, with the same attention to the user experience and with a consistent drive to simplify and make everything more intuitive. Complex systems don’t have to be presented with confusing software. But it takes more work to figure out the simple, elegant solution. It’s far cheaper and faster to make bad complex software than good simple software.

I also think there’s a business intelligence breakthrough afoot that will bring these same concepts of intuitive software specifically to the BI arena. Business intelligence is just a fancy way of saying that you’re extracting value from raw data in some way. This is typically limited to your mundane set of charts, gauges, and all the other normal dashboard UI elements that are the current standard. But I think thinking about BI problems from a fresh perspective, from the perspective of someone outside the enterprise space, will lead to the invention of new visualization methods. Maybe sales performance isn’t something best shown using a silly looking speedometer gauge. Maybe there’s an intuitive way to extract more value from that heap of raw data sitting on enterprise servers. But I don’t think enterprise developers have been willing enough to experiment with new concepts. People need to start inventing.

I have to agree that enterprise software is generally poor, particularly in the user interfaces.  In addition, his comments on working toward the simple, elegant solution makes me want to scream, “Yes!”  I think the only place I differ with him on is where the blame belongs for the overall low quality of enterprise systems.  Developers do deserve some of the blame, but I think generally the challenges come from the organizations, project owners, and managers who do not understand what is now possible, or even worse never understood how to build software to begin with.

In years gone by, the platforms really limited the ability of developers to build cool user interfaces that still made sense on the budget.  I was originally drawn to Flex because it can do things that simply weren’t possible on the web only a few short years ago.  This probably factors into the decisions that even smart, experienced managers are still making today, as many of them have previous attempts at doing cool things that led to ballooned budgets and jeopardized projects.

So, there is the obvious onus on developers to sell their ideas and educate their organizations on what is possible now that the platforms have capabilities way beyond getting data in and out of the database.  However, with that said, the real limitation of enterprise software will always be that the teams building most systems are part of companies that do not exist to build software, and often just don’t understand the processes, the platforms, the code, the users, etc.  In those cases, it is unlikely that they will be able to overcome their limitations to build cool, highly usable systems.  So, while I am optimistic that the advances that have come with the RIA revolution will trickle into the enterprise, it is unlikely that they will have the same impact on business applications as we are seeing in consumer applications built by companies that exist solely to build quality software.

If you enjoyed Doug in writing, check him out in this recent Flasher Magazine video interview. Also, look for him in a future DrunkOnSoftware.com interview.

I lived through the countless MVC frameworks in Java.  So, I don’t believe it is naive when I ask, what is so great about MVC anyway?  We all love to work in code where the separation of concerns (SoC) have been adhered to, but do I need MVC to accomplish this in Flex?  I don’t believe I do…

Anyway, back to Flight, they did allude to some additional features in the framework, like history management.   Although that specific feature is available in Flex 3, there maybe other features that make it useful.  The documentation is pretty slim right now – we will see what else is there when the docs evolve.  For me, I guess I want to see frameworks that do more than attempt to enforce a pattern.

An architecture is sufficiently defined when we can turn a developer loose on developing some piece of functionality and he or she obeys all design constraints, there is a minimal possibility of creating software that produces any of the above problems. If you’re conceptually bothered by being constrained, preferring instead to program in wide open spaces with the wind blowing in your hair, perhaps you would prefer to think of architecture as providing the freedom from choice.

Alex Papadimoulis post, Programming Sucks! Or At Least, It Ought To, takes it more from the realities of building business systems on a day-to-day basis.  He basically concludes that developers get too enamored with all the noise in the software world and need to focus on building features for the business:

As frustrating as it can be to work with the uninspired, sloppy developer, the contrary – the inspired-yet-misguided one – is several magnitudes worse.

Alex offered a list on how to approach the profession:

1) Learn the Business.
2) Serve the Business.
3) Learn Off The Job.
4) Code mostly Business. (If the overwhelming majority of your hand-written code isn’t domain-specific and doesn’t relate to the application’s purpose, then you’re using the wrong tools.)
5) Tedium is Inescapable.
6) Find Satisfaction Elsewhere.
… and, if all else fails…
7) Get Another Job.

I do love Alex’s post and believe he basically hits the nail on the head about the attitude we need to take toward the profession. However, I believe Stu has better captured the reality of building software systems. Things do change and evolve in software in ways that are both beneficial to the developer and the business. Thus, defining an architecture up front on how the system is going to be built is an essential step to allowing developers to focus on building features that have value to the business.  If we succeed when it comes to architecture, then we can get on to the boring parts.

One could even say that if presidential elections are about the economy, then when it comes to software: It’s Architecture Stupid.

Anyhow, as I dug in today I was pretty shocked to see how bloated Spring (and Hibernate) have become.  I have been guilty of throwing JAR after JAR at problems, but it was almost unbelievable to see how many dependencies each framework now has, which of course caused me significant versioning hell in attempting to get the right mix of JARs.  With each change, a tweak to libraries seems to come.

The other surprising part to me was the number of different options there are now for configuring Spring, and how difficult it is to find a clear path to follow.  I am huge fan of annotations, and I am glad that they added significant support in that area.  However, even though I now have a working setup, I have little confidence that I am completely inline with the best practices.

Our company’s founders, Stu and Ed, love to make the statement, “Freedom from choice.” It seems like a “lightweight container,” like Spring would follow this simple axiom.

Anyhow, I am posting my current project for feedback.  Let me know if you see any silliness or have feedback on how I can improve my setup.  It pretty basic so far … Hibernate with Annotations, Spring (Annotations, ORM support), and SpringSecurity.  Here is the project.

I am a big believer in the idea of “flow,” where developers find their rhythm and begin to move through things quickly.  Over 10 years in the software development industry, I have encountered two times where the projects I was on never reached a state of “flow” in any way.  Usually, no matter what the challenges, I find the team and myself reach this in some form.  So, it is actually kind of scary to be on a project where we haven’t found this state at all.

The first time I experienced this it was because the needs of an internal customer were so ambiguous and bogged down in politics.  So, we were never able to get a clear picture of what we were to build.  This instance ended with our entire team being laid off as part of large reduction in the work force through out the company.

In the current case, the requirements are quite straightforward and clear.  There is plenty of weirdness in them, but the fundamental function of the system is fairly simple.  From a functionality standpoint, it is probably the simplest system I have ever worked on, outside of dinky web site contact forms and the like.  So, what’s the hang up to finding the “flow?”

I believe it is the high coupling through out the system.  We are working with an internal development team, and our customer has mandated a fully data driven approach and implementation that does little to separate the meta-data from the data.  In most cases, the database tables are being propagated up to the presentation layer, which has created heavy dependencies throughout the system between all tiers of the system.

In many ways, I have always thought the industry was a bit to extreme with the desire to decouple every single little thing, and found many of the driving forces for doing the decoupling to be a bit silly.  However, I am seeing now how much total coupling limits team productivity.  It brings team productivity down to the level of the least talented- least motivated developer, as everyone is always waiting on everyone else.

I think there is a very natural level of decoupling in systems.  We don’t need to go crazy on this issue, but when the natural needs for decoupling are ignored there are many side effects, including killing the team productivity.

He basically said to be sure and contribute where it matters, don’t spend your career cleaning up after hackers, allow consequences to happen, the core domain is where the value is, and rewriting legacy systems is generally not a good thing (unless they are just too expensive to operate).

Another interesting thing he pointed out is that his writing on ubiquitous language is about a team, not about an entire organization.  He stated that single monolithic models do not work and differences are ok.  Groups just have to agree on how to translate things that are shared…

The most interesting point to me is the idea of allowing consequences to happen.  I find that most software developers are passionate (including myself).  It is hard for us to allow bad things to happen when we can see them coming a long way off, but I think Mr. Evans’ advice is dead on here.  We have to do our best to make recommendations in hopes that our organizations will avoid costly mistakes, but as my boss tells me often ‘we cannot save them from themselves.’

So, here is to focusing on the core domain, and making ourselves as valuable as possible…