Building features organically

I ran into this interesting post and wanted to share it with you:
http://marcelo.sampa.com/marcelo-calbucci/brave-tech-world/Building-features-organically.htm

This is how it begins:

One of the most interesting aspects of Agile development is to not build things
that you won't use now or over-engineer a component because "we might need this
in the future". That is a wonderful thing for developers and it does cut a lot
of complexity and time to deliver the feature, by consequence making it less
buggy.

Now, the rest is quite the same, so you can either go there or not.
But the first comment (and only one when I visitied) is pretty smart. And counting on you lazy fellows that you might not invest in following the link and scrolling down, here's what Mike comments:

I spec from the "top down" and build from the "bottom up". That way, I think I
have a more throught-out overall plan, and it eliminates implementing some
possible dead-end features. Specs are much more malleable and have far fewer
requirements from a quality point of view. So I find it worthwhile to be a bit
more expansive and "future thinking" in a spec. But when it comes down to
implementation, I try to do as you say - and build from the bottom up with the
minimum set of functionality that can be made to work consistently. You can then
decide when you've "fiddled" enough, and decide to ship the features to your
customers.

Well said.

Thinking Procedural From Object Oriented and Event Driven Back to Procedural Programming

Object Oriented Programming

Object Oriented Programming fits most of the applications we create today. The idea of methods or services, encapsulated into classes or components, with clear separation of concern, isolated from each other, is clear and obvious. This is the heart of the Object Oriented concept, of Component Based Development, of SOA, etc.


Event Driven Programming

Event Driven is another concept, raised mainly from User Interface applications, but also protocol stacks, state machines, message brokers and all kind of listeners in general, can be seen as based on event driven concepts. Event Driven does not necessarily relate to Object Oriented Architecture. But yet, it is not a simple procedural programming.


Other Non-Procedural

Other types of programming methods which are non-procedural in their nature may include Pattern Matching Programming (e.g. XSLT) and Declarative Programming (e.g. HTML, SQL; some view Object Oriented Programming as declarative, I disagree).


Thinking Procedural

All above - Object Oriented, Event Driven, Pattern Matching, Declarative Programming - keep us apart from the flow. We get used to ignore the flow, the entire end-to-end scenarios which eventually creates the system.

Long time since we created a pure procedural program. This made us stop thinking in a procedural way. Which is problematic, as eventually the program will run as a sequence and we have to make sure it will work properly.

Here come to rescue: Sequence Diagrams, Scenarios, XP User Stories, UI Storyboards and Test Driven Development. They were all invented to assist us solving the problem of forcing us back to "thinking procedural".

Bim Bam BOM

We had this strange bug recently, while trying to parse a perfectly healthy XML file we got an exception saying:

org.xml.sax.SAXParseException: Document root element is missing.

We could, however, open the XML file in the browser without an error. And also our XML editor took it without a problem. Yet, in our code trying to operate some XSL transformation using Xalan, we got the exception above. And the problem was not with the transformation itself, at least according to the exception. The problem is with the XML document starting without a root. Though the first character seen in the file was an opening triangle bracket...

Well, there are things beyond what you see.

To find out what is the exact stream of bytes that the transformer receives, and doesn't like, we added the simplest debug line, dumping the bytes from the file to screen, not as chars but in their value. There appeared to be two bytes before the opening triangle bracket of the XML: FF FE.

At this point, my friend and colleague Effie Nadiv (famous for his Hebrew site, and a UI authority and legend), shouted out: it's the BOM! Xalan doesn't recognize the BOM correctly!!

And without further ado he presented the file (same file) in text mode and in binary mode:

See the FF FE at the beginning? This is the BOM.

BOM stands for Byte-Order-Mark, added to UTF-16 documents to denote the order of the bytes in each two consecutive bytes creating a character. UTF-8 documents may also have BOM, but it will be redundant and have no mean.

To read more about Unicode, UTF-8, UTF-16 and BOM, you may want to go to:
http://unicode.org/faq/utf_bom.html
http://en.wikipedia.org/wiki/Byte_Order_Mark

But, before you rush to the above, a GREAT reading material to understand once and for all the entire encoding and charset thing:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) by Joel Spolsky.
This is a must read!

Specifically to solve the above problem we changed the doc to UTF-8 without BOM. Most text editors support conversion to different unicode transformation formats, and allow the user to decide whether to add BOM to UTF-8 or not (probably it's better not to add, just turn off the option underneath).

.

=========================================
Added 21/7/08:
------------------------------
Just found this old newsgroup entry on the subject...
http://biglist.com/lists/xsl-list/archives/200208/msg01302.html
=========================================