What happens when a customer asks for a simple new bit of functionality? Do you have to execute changes on four different systems, test each in isolation and in combination, involve a separate testing, infrastructure and operations team?
If so, your architecture is probably not service oriented. In this post, I will examine the real meaning of coupling, and how it relates to SOA.
After I switched from Movable Type to Wordpress as my blogging software, the comment spam problem has returned from the grave. So I’ve looked for good solutions for WordPress: I ended on a verbal CAPTCHA with a math question (which may also keep stupid commenters out - not that I have any of those, of course). I am considering some of the “fight-back” solutions out there too: Maybe returning a really big response really slowly when spam is detected, like Spammer Tar Pit.
If you have any experience or thoughts on the subject (or if my CAPTCHA is broken), please let me know.
These sort of puzzles are often presented as an exercise in “thinking outside the box”. However, if I were to “think outside the box”, I’d drill a hole in the ceiling of the basement so I could see the light bulbs. Clearly, that isn’t the intended solution, and most people wouldn’t think it would be a fair solution, either. The trick is to identify what “requirements” are real, and what requirements are imagined by the puzzle-solver.
When solving software problems, same technique applies. For example, my client for a chat application requested a link to the help information in the status bar. This would require some layout changes that I considered a little risky. Now, if I had suggested that the users didn’t need the help information, I would really be thinking outside the box. Instead, we ended up enabling privileged users to send URLs in a normal chat conversation, which was a piece of cake to implement. This way, the privileged users could help others with finding the rules. I consider this thinking inside a bigger box.
This is why I don’t care about thinking outside the box. Instead, look for the bigger box.
PS: Finding the bigger box is often easier if you work together. I spend an embarrassing amount of time trying to figure out the Petals Around the Rose puzzle. But when I sat down with my wife (who didn’t know it, either), we solved it in about 15 minutes (yeah, yeah, yeah, she solved it in about 10 minutes and only smiled cleverly until I got it 5 minutes later).
My article series on Lazy Loading will be published on java.net tomorrow. In relationship to the publication, I am taking down the original articles from my blog. Please go to Java.net for to read about lazy loading.
Update: The article was just posted last Tuesday. I have updated the links in this post.
Myopia: the inability to see distant objects as clearly as near objects. PreferredConsumer.com
What makes a good statement? In my experience, a good statement is one that people will disagree with frequently. One of the internal quality auditors at my company has an excellent plaque in her office: “If you and I agreed all the time, one of us would be superfluous”. So, in the spirit of disharmony: Agile development is all about being myopic, that is, short-sighted.
One of the things that has always impressed me with people preaching waterfall, RUP, or traditional CMMI is how skilled they are at looking into the future. For me, this has never worked out well. I keep writing down requirements for projects that never happen, design my systems for requirements that turn out to be canned in the end, and coding my designings in a generic way, just to find out that the generic way I have designed the system, is different from the genericity that I really needed. *sigh*. I need a better crystal ball.
When I see people after they have read about SOA or attended a conference with SOA, there are a few ideas that seem to pop up repeatedly. I have even been guilty of using these ideas myself. These ideas were proven to be bad before SOA came around, and (some) SOA evangelists seem to think that SOA solved these problems. It did not. It just refused to learn from history. Some of these ideas work under some circumstances, but recent SOA-itis has caused them to be used in inappropriate contexts.
Subscribe (atom)