CRYPTOCHAOS

The fact of the matter is that too many people think that projects can be run through the interface of stories and feature lists without paying attention to the quality of the software underneath. And, when you don't pay attention to it, it suffers. This, really, is _Joel's Law of Leaky Abstractions_ applied to process. Business wants to see features, and if that abstraction is their only view of the project, they will be blindsided by creeping quality issues. It's nearly inevitable.

via .NET Rocks!

• "My point of view is that legacy code is just code without tests."
• "What's important is to try to imagine something that is just a bit better than what you have currently. If you can target those things, then over time you will really start to make a difference in the code base."
• [in order to reduce fear of a legacy codebase perform a scratch refactoring...] "Check out the code with no intent of checking it back in. Refactor different sections... enough to get a feel for the code base, to get a handle on it..."
• "Functional languages get us away from some of the issues that have become so problematic in testing... Functional programming reduces the number of side effects of code..."
• "C# is getting too big. Every time you turn around there's been something added to the language. I'd hate to see it end up like C++."
• [regarding the new raft of languages] It's a bit like the tower of babel. For so long we had a mono culture in the industry around java and visual basic. Now it's at the point where everyone and their brother is designing a new language."
• [Regarding OO languages hitting a wall] "I think there is something to that, but I also think it has to do more with the type systems."
• "There are two basic themes of type safety... Type inference and Laziness, create data structures and apply limitations after the fact. I recommend that people learn Haskell. It really throws your mind in strange directions."
• [Regarding OO programs becoming legacy...] "It seems to be the fate of everything... Progress happens."
• "The history of the next 30 years will be about mining the last 30 years"
• "The thing about learning Haskel... it's great... You just need to learn to think like a martian!"
• "When you're choosing the right tests for something you have to think about it very deeply. you have to understand exactly how it operates... as you go through that process you'll arrive at higher quality without necessarily putting the bugs in there in the first place. So TDD and unit testing in general gives us quality, not through just test failures, but by forcing us to think through our code deeper than we would otherwise."
• [Regarding Agile] "The only thing that gets me is that there seems to be a moratorium on design in the industry over the past 10 years. There was a time when peopled talked about the intricacies of object oriented design... Once you go ahead and say 'Design is going to emerge' people say 'oh well then, we don't have to talk about that'"
• [Regarding the question: has architecture been forgotten"] "I think to a degree... there are some not nice things that have happened with the nominal title of architect over the past 20 years. But architecture expertise is definitely necessary in many application domains but they have to have a real view into the code."
• "Architecture knowledge has to be in the team... It's a very communicative role."
• "The import thing is continuity of knowledge in the team... When you have that, everything works out well... When you don't, everything is a fishing expedition when you need to make changes.
• "Documentation is important but you don't want to get into the situation where everything is exquisitely detailed and has to be changed every time you change the code. It gets crazy."
• "If you see code that is crazy and odd and you understand Conway's law, it really says something about the team that produced it. If you need to produce code in a team effort, than that team needs to get along together in order to produce good code. Otherwise, they are just sabotaging each other... even if only subtly."
• Emergent design can work very well, but in large organizations with a large codebase you have teams that do a little work on some code and move on, a little work on other code and move on. With agile, the original goal was to have collective code ownership. In large organizations there is no ownership so you have an odd tragedy of the commons. In large organizations, there needs to be a notion of ownership and if you don't, you shouldn't be surprised with what you get."

 

Transcript from an interview with Charles Eames on French Television 1972

You should definitely click through to read the entire transcript.   Eames' answers are very zen.  The high impact of thought with few  careful words seems to be self referential to his design ethic.

The bottom line is that customers usually aren’t very good at describing solutions. But when properly asked, they’re very good at describing their needs – what they like, what they don’t like, what makes their lives hard or easy, what they wish for, and what they’re trying to get done. And after all, it’s not the customer’s job to come up with the solution – that’s the developer’s job! Their job is just to articulate their needs.

Posted @ Friday, October 16, 2009 10:07 AM by Michelle Harris

The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are:

1. You must ask the right questions to get valuable answers.
2. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information.
3. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.)

Of course, this is not a new metaphor.  BPM folks have been using the concept of “white space” for a while.   BPM professionals usually use the term “white space” to refer to the gap between process steps.  That gap is important to the Enterprise Architect as well, but the EA does not stop with the gap between business processes.  An EA is also interested in the gap between business entities (information), the gap between business functions (business), and the gap between integrated systems (integration).

Looks like the tide of the web API protocol war (if there ever was one) has shifted firmly in REST’s favor while SOAP has been forced back. Web developers have cast their votes, they want RESTful APIs.

...

Source: ProgrammableWeb, May 2010.

Will 2010 be remembered as the tipping point when Software Architecture became "composite" instead of monolithic? Five years after the first official mash-up was published? Critical building blocks are still worked on, like OAuth, while new types of clients are appearing almost daily. It seems now that the momentum behind composite applications is inescapable

A software architect who doesn’t care about what his system is supposed to do isn’t worth his salt. For the term “software architect” to hold any meaning at all, it must be to describe someone who understands what the customer needs and designs a system that is fit for this purpose.

 

Summary
Stefan Tilkov discusses SOA basic concepts by making a number of claims, such as “Application architecture is irrelevant for your SOA” or “An ESB should not be at the core of your SOA”, followed by explanations and related recommendations.

 

Level headed discussion of REST vs. WS-*