[Spirit FM] mikereidis:
Post 5000 reserved for some developer humour & the not necessarily so humorous relationship to the god-awful mess the Spirit1 code has become, and why it needs to go the way of 2012, and welcome 2013.

The season and the massive slowdown (but not stop) of Spirit1 development gives me an opportunity to spend a bit of time updating my skills/knowledge and tools.

Doing so, I came across this, which isn't the funniest developer humour, but a good read & laugh none-the-less: http://www.codinghorror.com/blog/2012/07/new-programming-jargon.html

You'll likely need at least a bit of software development knowledge to get much out of it.

I've always preferred "3. Egyptian Brackets" and I guess I got that from K&R C in the 1980's and stick to it still, even in other languages such as Java. Whatever, it suits me & is just personal preference.

The last, "30. Jenga Code" likely has many names, but I think is more common than non-developers would imagine, including in some of the multi-decades old old code that still deals with some of our banking transactions. Thankfully they test a lot, and redo things when needed, when it comes to most financial stuff.

Their definition is: "When the whole thing collapses after you alter a block of code."

Now I wouldn't say Spirit1 completely collapses when a bug is fixed or a feature is added, but it's become VERY difficult to do these without causing at least one bug needing later fixing.

This is usually why, when I update Spirit on Google Play once a month or so, you will usually see several smaller further updates over the next few days. I release, new bug reports come in, and I deal with them, trying to be careful not to create new, new bugs. And releasing them here on XDA only gets a hundred testers or so in a week or two, while releasing on Play means thousands of testers.

The other day I added an Unlocked feature that turns the on screen UI seek buttons into the same as media buttons. It works, the person who wanted it is quite happy, but he reported a few bugs I'll have to tackle.

There's almost no such thing as a "little change or fix" when dealing with mountains of legacy code, with hundreds of strange hacks here and there that were hurriedly added. The responsible companies I've worked for do a LOT of testing for each release. We'd document the known bugs, and any workarounds, instead of trying to throw in a last minute fix that could break other things. This is called a "code freeze" (but there are often exceptions, and some very important code can thaw a bit, especially to accommodate very important customers.)

Spirit1 was built quickly, and not really designed. Features and phone support were added quickly, using many shortcuts and things good developers know they "shouldn't" do.

That's fine, that was the need and strategy for the time. But now the weight of it all is too much, and it's time to more or less start over (although blocks of code & logic & knowledge will be retained, cleaned up and re-used).

I know some (many ?) people will feel that Spirit1 has "left them behind". I think my best response is:

"I hope you'll eventually get a Spirit2 supported device, and come to appreciate that I left the older devices behind to concentrate on the new".

As a quick re-stated example: Why should I spend hours trying to put a new feature into Spirit1, when I could add that feature in minutes to Spirit2. Multiply this by a thousand small new features and bug fixes.