Stu Stern originally posted this on Big Gorilla - Stu Stern's Blog.

Yesterday I discussed how we developers routinely deal with imprecise requirements and while most of us find this to be annoying from time to time, overall we don't consider this a Big Problem. Or perhaps many of us do recognize this as a Big Problem, but have resigned ourselves to its seeming intractability. In any event, we can all agree that if it were possible for us to unambiguously "encode" requirements precisely, and could do this economically, it would surely be better than the current, preferred practice of getting a "pretty good idea" of what some business guy needs, code it up, and then sit down with the guy to see what we got wrong, and come away with a "pretty gooder idea" than we had previously. And then repeating this process over and over again until we get it right or until it's time to go live.

Most development projects begin with a fuzzy expression of requirements as articulated via some combination of text, pictures, and threatening emails by some end users, and end with a concrete expression of requirements as expressed in code and entreaties for forgiveness by programmers. As we discussed, there is currently no widely recognized middle ground between the fuzziness of warm, friendly natural language-based requirements specs, and cold, hard code. As a result, developers are left to interpret the fuzzy as their first step toward implementing a solution. Precision Requirements Modeling (PRM) is a set of techniques for transforming fuzzy requirements into a "code-ready" requirements specification. PRM allows requirements to be expressed with the precision of code, without getting bogged down in requirements details. Perhaps most tantalizingly, PRM specifications are themselves executable, which means we can let end users test drive a specification prior to developers becoming lost within the dense tangle of the implementation jungle, where they become increasingly isolated from civilization as they fashion primitive tools and frameworks, and engage in pitched warfare with competing tribes using .NET.

PRM begins with good-old-fashioned domain modeling. Virtually all O-O developers engage in some level of domain modeling whether they realize it or not. Every time you specify a class that represents a business concept, you're engaging in domain modeling. Even the staunchest of anti-modeling activists can often be caught in moments of weakness drawing UML-ish boxes and lines on a whiteboard. Anybody who has worked on anything but the most trivial of applications has come to recognize the usefulness of UML class diagrams or, at a minimum, entity relationship diagrams as a way of allowing members of a team to get a shared understanding of the major abstractions or data representations being used and how they relate to one another. Of course, you can always just fire up a debugger and trace through your buddy's code, but most of us would prefer a less - uh - extreme approach to integrating the disparate pieces of an implementation.

Class diagrams and ERDs are some of the best ways of communicating among a team an application's entities, their attributes, and their relationships to each other. In terms of attributes, most developers specify no more than names and types of what will be persisted. But as we shall soon see, class diagrams have the potential of communicating so much more if we would just let them. How well do you really know class diagrams? Sure you draw them occasionally. Sometimes you may even bring them to lunch with your colleagues. But if you would just get to really know them, you would see that they're among your best friends.

In our next installment, we'll get better acquainted with some class diagrams and see how, with some minor extensions, they can be used to unambiguously specify large portions of any requirements specification, and bridge the gap between warm, fuzzy business people and cold, hard programmers.

jonr originally posted this on Jon Rose's Blog.

I was chatting at the office last week about code quality, and thought I would jot down some of the things we talked about.  I think it is fair to say that it is difficult to know when code is “good” and when it is “bad.”  There are of course obvious times when the coder was incompetent, or cut corners with little explanation.

Ignoring those types of issues, judging code is difficult because we do not understand the reality of when the code was written.  Was the code written with an extreme deadline?  Was it built with a clear expectation of being prototype code and then put into production by some aggressive manager?  Was the architecture changed multiple times without time to rewrite / refactor?

In addition to not understanding the actual circumstances around the time of original development, developing perfect code is expensive and there is a point where we all need to ship our imperfect code and move on.  Only a really rich, somewhat misguided, client would pay for the real amount of time to develop perfect code.  And of course, we have to understand that much of our feelings toward code come back to style and preference, and not everyone has the same approach to these items.

So, let’s all try and buck the tradition of bashing the last guy’s code, and when there are real issues that need to be addressed then please approach them gracefully.  Remember, someone will be following you soon too!

Stu Stern originally posted this on Big Gorilla - Stu Stern's Blog.

One of the things you gotta love about "agile" is the name. Is it ever bad to be "agile"? Is there a good alternative (other than synonyms) for "agility"? Here at Gorilla Logic, we've devised what we modestly consider a breakthrough approach to requirements definition. "Precision Requirements Modeling" is the best our marketing department has been able to come up with as the moniker for this new approach. Although mind-numbingly accurate in its characterization, the name lacks a certain zing. Perhaps "Naked Precision Requirements Modeling" would be better.

While all developers want to be rich, thin, agile, and left alone, the same cannot be said of their wanting to be "precise". This is a curious thing when you consider that programming of course is nothing if not "precise". Code specifies precisely what the system will do. For the time being at least, computers don't have the ability to ponder a set of instructions and decide how best to carry them out. Programming code is literal, bereft of simile, metaphor, and clever double entendres. Functional requirements on the other hand are captured as natural language either because they're being written by non-programmers, or because they need to be reviewed and approved by non-programmers. Natural language tends to be pretty imprecise. (That's why we need programming languages.) Our industry has thus become accustomed to routinely working with imprecise requirements specifications.

Now some will argue that natural language can be quite precise. Aren't legal contracts shining examples of precise, natural language? Perhaps the world needs more lawyers. On the other hand, legal contracts tend to be fairly unintelligible to non-lawyers, and although I can't prove this, I will assert that most lawyers would make crummy programmers. Since non-lawyers are going to be writing the code, we probably need something other than legalese to communicate requirements.

Some will say, "aha"! This is precisely why striving for precision in requirements is a waste of time. "Those wacky business people can't possibly know if they want something or not until they see it running on their own desktops anyway". To a large extent this is of course true, but the number of cycles required to get things accepted by an end user will surely be reduced in direct proportion to how well we can understand the requirements prior to writing each round of code. Many theologians will say that although better requirements will reduce the cycles, they don't necessarily reduce the overall effort, since we're just substituting time spent requirements writing for time spent coding (and wouldn't you rather be writing code right now?). In fact, given what we've discussed about the imprecise nature of natural language, aren't we just better off capturing the requirements as code rather than trying to turn a requirements specification into a legal contract?

Perhaps. But this argument ignores the fact that when we code, we deal with far more than functional requirements. As much as 80% of code can be concerned with implementation details as opposed to business logic. (Actually, I just totally made up this statistic, but if you write code, I'm sure you'll agree that a very large proportion of code is solely concerned with plumbing). So the problem is that when we run off and code up a set of loosely defined requirements, we spend a whole lot of time dealing with implementation details that along with the business logic will need to be redone if our interpretation of those requirements is somehow incorrect.

Ah, but isn't this what "refactoring" is all about? The answer to that question is "no". Refactoring is about cleaning up an implementation. It's about avoiding over-engineering by just writing the damn code, and then restructuring that code when it becomes unwieldy, rather than building elaborate frameworks before we truly understand what our implementation requires. "Requirements refactoring" is a euphemism for getting things wrong. When we need to "refactor code" to reflect a requirements "clarification", we are simply rewriting code that was written to do something nobody actually wanted.

If there were only some way to "code" requirements without having to deal with implementation details. Then, we could indeed use code as our medium for capturing precise requirements, without wasting a lot of time on unneeded implementation should those requirements prove inaccurate. Hmmm, if only there were some way to capture requirements as code without implementation details.... Oh, that's right. There is a way. And coincidentally, it's what we've been working on for the last six years here at GL.

jonr originally posted this on Jon Rose's Blog.

Corner-Case-Driven-Development is an exciting version of development where all extreme corner cases are highlighted each step of the way.  It is especially important to interject a corner-case once someone starts to talk about the fundamental features of the system, as getting distracted by the core things, like what a user wants to accomplish, is a no-no in the corner-case methodology.  When embracing corner-case-driven-development, a team can expect a number of exciting things to happen, including: difficulty developing and maintaining the code, un-met deadlines, and generally low team morale.

Read about more exciting methodologies here: http://www.scottberkun.com/blog/2007/asshole-driven-development/.

jonr originally posted this on Jon Rose's Blog.

I am listening to the latest Java Posse podcast, a session from this years round-up titled, Don’t Repeat Yourself. In the discussion, Tor Norbye made the statement that, “programming is all trade-offs.”  This is a great point.  For what ever my strengths and weaknesses are as a developer, I have long believed that one of the main values I bring to each of my projects is a natural cost benefit analysis mechanism.  It seems that most anything is truly possible in software these days.  So, understanding the costs of each decision is one of the most important parts of building quality software.

jonr originally posted this on Jon Rose's Blog.

Well, I have been pushing him to get in the Blogging game for a while, as he brings a unique take to all things software.  He is our CEO that codes.  I don’t know what that says for his CEO skills, but for us developers it makes for a great boss.  Anyhow, here is the official introduction to Mr. Stu Stern’s blog, Big Gorilla.

jonr originally posted this on Jon Rose's Blog.

In Thomas Friedman’s latest article, he suggest we have Steve Jobs run the car companies for a year, as part of a bail out deal.  After living in an IT industry built on inovation for the last decade, it is hard to understand how our automakers have failed so clearly in this respect.  And, it is even harder to see them heading towards a taxpayer bailout when it is sink or swim for the rest of us.  How do you ever get better if you keep getting bailed out?  Its like the kid given too much early in life… it is almost impossible for them to ever break the cycle.  I hope its different with our automakers.  I hope Mr. Jobs is offered the job and accepts.  I doubt he will fail to innovate!

jonr originally posted this on Jon Rose's Blog.

Well, this seems like a stupid statement, but for me, “Flex is Java!”  We have heard a lot the last year about Java the platform versus Java the programming language, with the push to add scripting languages to the JVM and add extensions beyond the core programming language.

When you look at Flex you find that Data Services is built to run in a Servlet container.  The IDE is an Eclipse plug-in.  The only thing that really breaks from Java is that the client runtime is not a JVM, but Java has basically failed to ever deliver a viable client side runtime for browser-based applications.  So, why not consider Flex / Flash for this option?

That is actually where my statement comes from, as I think Sun should have started claiming, “Flex is Java” in 2007 as a marketing campaign, rather than starting their client side initiative, JavaFX.  Even if JavaFX ends up becoming a viable technical option, how will Sun ever profit from it?  I know-I know, I read Jonathan Schwartz’s blog and hear they are making money on Java, but in all seriousness… why doesn’t Sun promote things like Flex as successes of the Java platform? Is it just another case of “not built here syndrome?”

jonr originally posted this on Jon Rose's Blog.

I found a few extra minutes and decided to read through an article I wrote last summer titled, From Java to Flex.  I hope that isn’t as narcissistic as it sounds, but I like to continue to learn and evolve and I thought I would see how much I still agree with myself.

Well, I made it to the second paragraph before I had to disagree with myself, “… developers should be considering the adoption of Flex is the maturity of the framework.”  It is hard for me to argue this point since I just blog about the Flex Immaturities. I still think Flex is worthy, and would argue that the wealth of off the shelf components for Flex makes it mature in a certain way.  The API’s are somewhat immature, but so many “UI Frameworks” don’t offer any real component library, so this is a big help in Flex.

I did a decent little review on LCDS.  Since writing the article, Adobe open sourced BlazeDS, which was an important step to give the community another open source option for remoting with Java backends.  BlazeDS does breakdown with any large scale push deployment, but this was still an important step forward.

Another thing that stands out is that I have the standard Adobe pitch in there that ActionScript is ECMAScript.  I have since concluded that this a silly pitch.  All I can figure on is that it feeds Adobe’s marketing claim on the large number of people who know their programming language (i.e. because they include all the JavaScript developers).  I think they should scrap this and start making the language better with abstracts and private constructors.

I don’t spend much time on AIR in the article.  I do see that AIR can have value, but I still see it as a weird fit for so many applications.  I guess I just don’t see it as much of a game changer as Adobe does.  I kind of like David Heinemeir Hansson’s take, You’re Not on A Plane.

I still strongly believe that Flex is a natrual extension of Java.  I am going to write a full post on that, so I wouldn’t go into that here.  I guess I still really like Flex.  I have seen more of its warts, but it still the best option I can find, as it offers a full suite of components essential for building enterprise applications.  This seems like a trival point, but I believe it is the key.  Shouldn’t all UI frameworks offer a full suite of components?

jonr originally posted this on Jon Rose's Blog.

I was talking with a Ryan Knight, a co-worker at Gorilla Logic, about our general impression of Flex.  We are both developing significant functionality with Flex these days, and we quickly agreed that are some real pain points.  I boil most of these down to immaturities, and do expect Flex to overcome most of these as the platform matures.

One of Ryan’s examples was the Flex Date class, which for some odd reason is final.  This is of course problematic, and a bit bizarre to have something like this be final.  This caused Ryan’s projects challenges because the default behavior was causing issues, and they had to override the AMF serialization to overcome the issue, which is overly involved.

A similar pain for me was ArrayCollection (see previous post).  In my previous post, I didn’t discuss our attempts to extend ArrayCollection to control the typing when they are created from our Remote call.  First off, I was quite surprised to realize that ArrayCollection doesn’t have its own interface, as my first attempt was to hold the data in an Array and lazy instance the ArrayCollection by delegating to a private ArrayCollection.  Second, I tried to extend and wanted to not call the super constructor, but this was problematic because the compiler inserts super even if I omit it. Anyhow, as each typical object oriented approach ended in a road block, it seemed to being highlighting a real immaturity.

I won’t bore you with all the issues we banter about, but it is important that Flex evolves in the next 12-18 months.  Also, I do respect how difficult it is to design a good API, and I am not claiming that I would fare any better.  All that said, I am hoping to see the framework take huge steps forward with next year’s Flex 4 release.

I hope you made it this far because I did bury the lead a bit… Ryan and I both agree we still love Flex overall, and that wealth of components still makes it possible to build things simply not possible in many of the popular Java frameworks.