One Man Bands

R.A. Hettinga wrote:
> At 5:55 AM -0700 9/6/07, Adam C. Engst wrote:
>> And my Classics degree is appreciating all the literary references...
>> :) That means Odysseus will just have to navigate between the Scylla
>> and Charybdis of Mail and Gmail... ;)
>
> Didn't Steve Dorner build Eudora all by himself in the first place?
 
 
I read an essay about "rewriting" software a while back. It was about why it many times results in a terrible end product. The above comment about Steve Dorner and my own experience in the past only reinforce the conclusion.
 
Think of an old commercial building that's been remodeled many times over the years. When you walk around in it you see all these little hallways, closets, etc... that seem to be "out of place" but if you dig deep you find out that the seemingly out of place closet on the 8th floor has to be there due to the electrical conduits running through it. And those conduits are there because there was no practical way to reroute them during the remodel of 87 without turning off power to the phone system on floor 33 for 12 hours and that would ..... So you have this odd closet that was left behind with conduits running in the false back wall. Now someone surveying the building to make up plans for a new one might think that some kind of storage closet was needed when the tenant moved but would be way wrong. The real reason had nothing to do with storage and was basically unrelated to the space.
 
Software with a long history of revisions works the same way. I dealt with a business application where I was one of two people who really understood the whole of the package and it was fairly intricate. And from what little I know of email the same could be said in terms of intricacy. Over the years most software like this grows all kinds of strange scars, warts, transplants, etc... which when looked at in isolation appear to just be some messy code that can be cleaned up by a sharp coder with a fresh pencil. When you start actually doing this job you find out things like this bit of code handles the way Cisco firewalls can mangle certain transactions in ways that Cisco feels is OK but you and many others feel breaks the standards. But since there are literally 1000s if not 100,000s of these things out there you write code to deal with it. And code to deal with IBM's Domino server, Microsoft's Exchange, Novell's Groupwise, and even Bind. Successful packages which deal with c
omplicated situations become filled with these things over time. And what it means is that you either figure out how to re-write while incorporating all these (many times poorly understood by the current team) items. Or you re-write to the "standards" and spend years incorporating all that messy code functionality that the "old out of date" product had in it. Relating to my own experience I spend about 1/3 of my time on a 2 year re-write explaining to the team why we needed to incorporate all kinds of warts they wanted to leave behind.
 
Basically for an old software product to survive it is in many ways a mater of luck. Did the developers make a choices years ago that seemed trivial at the time but that now allow the product to be "improved" in ways that are now considered important? Or did they make the OK then but bad now choice that makes it almost impossible to incorporate new desired features. Hind site is great but it doesn't help change the way the world turned out.
 
David Ross

On 9/7/07, David Ross <drdavidrossconsultant.com> wrote:
> I read an essay about "rewriting" software a while back. It was about why it many times results in a terrible end product.
>
> Basically for an old software product to survive it is in many ways a mater of luck. Did the developers make a choices years ago that seemed trivial at the time but that now allow the product to be "improved" in ways that are now considered important? Or did they make the OK then but bad now choice that makes it almost impossible to incorporate new desired features.

I realize this is a massive digression, but it seems especially
pertinent to us Mac users right now. Why? Well, a few years back we
suffered (and survived, mostly) a total re-write of our operating
system. (Which, I might add, failed miserably a few times before -- it
took NextStep's mature code-base with some major renovations to create
MacOS X.)

Furthermore, a number of products were re-written from scratch in
order to work with OS X (or to take advantage of Cocoa's ease of
development). In a few months, we'll be seeing what may be the highest
profile re-write: Microsoft Office 2008.

As someone who works with a lot of programmers, I hear "Let's just
scrap this code and start fresh" more often than I care to. Sure, the
code in question is often buggy, inconsisent, poorly documented, and
otherwise a real drain on resources. But every time we have gone down
the road of demolishing what came before and starting fresh, we make
major compromises in functionality.

What was, to the programmer, a poorly implemented hack that caused
major performance issues, was a key feature for our marketing group or
to our end users. That tweaking, enhancing, and change over time (the
maturity of the product, if you will) is next to impossible to rebuild
from scratch. (Although a well-managed re-write will certainly capture
a lot of those hacks as must-have features in the new release.) It
seems as though it must grow and evolve organically.

--
Nik

nikinik.net | http://inik.net | http://notions.inik.net

David:

There is lots of old code in Eudora that needed a rewrite but the biggest problem that came back to haunt was Eudora was not moved to XCode when Apple started suggesting it.

Without being in XCode, a Universal Binary would not be easy when Apple switched to Intel but who knew?

Having to switch development environment and rewrite at same time would be a big job.

--Jim

On 09/09/2007 06:40 AM, "Nik Friedman TeBockhorst" <nikinik.net> wrote:

> Furthermore, a number of products were re-written from scratch in
> order to work with OS X (or to take advantage of Cocoa's ease of
> development). In a few months, we'll be seeing what may be the highest
> profile re-write: Microsoft Office 2008.

No, actually, it was not "re-written from scratch" as a cocoa application.
The idea that "Cocoa always = Better" is a myth, and a silly one at that.
Office 2008 had to move to Xcode, deal with becoming a Universal Binary, and
then the changes in Office on the Windows side, but it's not a line zero
rewrite.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

--On 9/9/07 11:50 PM -0700 John C. Welch wrote:

> On 09/09/2007 06:40 AM, "Nik Friedman TeBockhorst" <nikinik.net> wrote:
>
>> [...]In a few months, we'll be seeing what may be the highest
>> profile re-write: Microsoft Office 2008.
>
> No, actually, it was not "re-written from scratch" as a cocoa application.
> The idea that "Cocoa always = Better" is a myth, and a silly one at that.
> Office 2008 had to move to Xcode, deal with becoming a Universal Binary, and
> then the changes in Office on the Windows side, but it's not a line zero
> rewrite.

And in fact, the decision to discard Visual Basic for Applications (VBA)
scripting from the Mac OS version of Office was largely made because that code
WOULD have required a line zero rewrite.

Dave Scocca

> > Furthermore, a number of products were re-written from scratch in
> > order to work with OS X (or to take advantage of Cocoa's ease of
> > development). In a few months, we'll be seeing what may be the highest
> > profile re-write: Microsoft Office 2008.
>
> No, actually, it was not "re-written from scratch" as a cocoa application.
> The idea that "Cocoa always = Better" is a myth, and a silly one at that.
> Office 2008 had to move to Xcode, deal with becoming a Universal Binary, and
> then the changes in Office on the Windows side, but it's not a line zero
> rewrite.

If I understand the posts on the MacBU blog (and it's entirely
possible I don't), they are moving a great deal of the code over to
Cocoa (and, one would hope, maintaining some legacy "carbon" code
rather than doing a complete re-write, as you say).

Regardless, this is a major, and important, application suite upgrade,
and does represent a substantial re-write of code and re-work of the
interface.

In any case, I didn't mean to imply anything about Cocoa being better
than Carbon.

--Nik

On 09/10/2007 09:59 AM, "Nik Friedman TeBockhorst" <nikinik.net> wrote:

>>> Furthermore, a number of products were re-written from scratch in
>>> order to work with OS X (or to take advantage of Cocoa's ease of
>>> development). In a few months, we'll be seeing what may be the highest
>>> profile re-write: Microsoft Office 2008.
>>
>> No, actually, it was not "re-written from scratch" as a cocoa application.
>> The idea that "Cocoa always = Better" is a myth, and a silly one at that.
>> Office 2008 had to move to Xcode, deal with becoming a Universal Binary, and
>> then the changes in Office on the Windows side, but it's not a line zero
>> rewrite.
>
> If I understand the posts on the MacBU blog (and it's entirely
> possible I don't), they are moving a great deal of the code over to
> Cocoa (and, one would hope, maintaining some legacy "carbon" code
> rather than doing a complete re-write, as you say).

Where they're doing rewrites anyway, or the codebase is fairly small that's
happening, such as Messenger and Remote Desktop Client. But in the bigger
applications? Nah, the move to Xcode hurt them enough as is. Unlike Adobe,
where you have one group doing both versions, so they can have a rather
large amount of common code, the Mac BU office team has to work with the
WinOffice team. For example, they had to wait for the final version code
drop of Office 2007, so that they knew all the new file format code was
finalized. Using a beta would have been bad, because between the next to
last and last betas of 2007, there were major changes in the file handling
code and the file formats themselves. So had the MacBU been working with
that code, they would have had to junk a lot of what they'd done. That's not
even close to easy.

While I do get frustrated, and quite vocally so, (if you know anyone in the
Mac BU, ask them how vocal I get ;-), I also understand that comparisons to
Adobe are not that valid, because the relationship between the MacOffce and
WinOffice teams are VERY different that the Mac and Windows teams at Adobe.
Between that difference, and the move to Xcode, they've had a fairly rough
time of it. Doesn't mean I won't gripe about things I think are wrong, but I
do try to keep in mind WHY things might be wrong.

>
> Regardless, this is a major, and important, application suite upgrade,
> and does represent a substantial re-write of code and re-work of the
> interface.

Indeed. But to assume "Cocoa" in all cases is just incorrect, that's all.

--
John C. Welch

Dave Scocca wrote:
>
> --On 9/9/07 11:50 PM -0700 John C. Welch wrote:
>
>> On 09/09/2007 06:40 AM, "Nik Friedman TeBockhorst" <nikinik.net> wrote:
>>
>>> [...]In a few months, we'll be seeing what may be the highest
>>> profile re-write: Microsoft Office 2008.
>>
>> No, actually, it was not "re-written from scratch" as a cocoa
>> application.
>> The idea that "Cocoa always = Better" is a myth, and a silly one at that.
>> Office 2008 had to move to Xcode, deal with becoming a Universal
>> Binary, and
>> then the changes in Office on the Windows side, but it's not a line zero
>> rewrite.
>
> And in fact, the decision to discard Visual Basic for Applications (VBA)
> scripting from the Mac OS version of Office was largely made because
> that code
> WOULD have required a line zero rewrite.
>
Now on the flip side, MS Access has never made it to the Mac supposedly due to much of the core code being written in x86 assembly. And this would be a VERY understandable reason. But now that Apple is x86, I wonder what reason might be given now as to why it will not be ported.

And to be honest I wonder how much a new version VBA for the Mac office could be lifted (with some non trivial effort I suspect) from the windows side. But of course with MS saying VBA is going away on windows I guess implementing new support on the Mac side would look bad. I do wonder though how long it will be on the Windows side. Things like this tend to live for a LONG time. :)

David Ross

On 09/13/2007 00:48 AM, "David Ross" <drdavidrossconsultant.com> wrote:

>> And in fact, the decision to discard Visual Basic for Applications (VBA)
>> scripting from the Mac OS version of Office was largely made because
>> that code
>> WOULD have required a line zero rewrite.
>>
> Now on the flip side, MS Access has never made it to the Mac supposedly due to
> much of the core code being written in x86 assembly. And this would be a VERY
> understandable reason. But now that Apple is x86, I wonder what reason might
> be given now as to why it will not be ported.

It's also VERY tied to Windows. Lots and lots of deep OS hooks in Access
that the others don't have.

>
> And to be honest I wonder how much a new version VBA for the Mac office could
> be lifted (with some non trivial effort I suspect) from the windows side. But
> of course with MS saying VBA is going away on windows I guess implementing new
> support on the Mac side would look bad. I do wonder though how long it will be
> on the Windows side. Things like this tend to live for a LONG time. :)

From what I've seen, Office Next on Windows has a high chance of losing VBA
in place of VB.NET, which would be more platform-portable.

--
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
jwelchbynkii.com

On 12-Sep-2007, at 23:48, David Ross wrote:
> Now on the flip side, MS Access has never made it to the Mac
> supposedly due to much of the core code being written in x86
> assembly. And this would be a VERY understandable reason. But now
> that Apple is x86, I wonder what reason might be given now as to
> why it will not be ported.

Well, they might have to reveal their real reason, they don't want to
do it and no one cn make them do it and they don't want to lose
market share for Access Apps that run on windows (and there are a
billion of these) to Mac OS X.

--
"Woof bloody woof."

David Ross speculated and pondered...

>Now on the flip side, MS Access has never made it to the Mac supposedly
>due to much of the core code being written in x86 assembly. And this
>would be a VERY understandable reason. But now that Apple is x86, I
>wonder what reason might be given now as to why it will not be ported.

IMHO, the appearance of MS-Access was due to the release and success of
Filemaker for MS-Windows. FM became the best selling database program
for Windows. I believe MS developed Access and added it to MS-Office for
Windows to keep the competition from getting the entire market. A
strategy not too far from giving away Navigator to crush Netscape. When
IT folks are asked for a db recommendation they only need to point at
the MS-Office package. Interestingly, some people have referred to
Access as the world's most widely distributed unused application. FM
repeatedly receives the highest ranking and "Editors' Choice" awards for
MS-Windows DB programs in PC Magazine.

- Hank

One opinion: There are two well known applications which tie for the
"Most User-Antagonistic of ALL Applications" title: MS Access, and
Quickbooks. I will avoid both to the greatest possible extent! I
realize and accept the idea that others may feel differently, but
such is MY opinion.
Don Power

>Now on the flip side, MS Access has never made it to the Mac
>supposedly due to much of the core code being written in x86
>assembly. And this would be a VERY understandable reason. But now
>that Apple is x86, I wonder what reason might be given now as to why
>it will not be ported.

Here's one good one I can think of: the current installed base of
millions of PPC Mac-owning Microsoft Office customers. Don't forget
the PPC half of 'Universal Binary'.

>
>And to be honest I wonder how much a new version VBA for the Mac
>office could be lifted (with some non trivial effort I suspect) from
>the windows side.

Same thing- you're still leaving the PPC base out in the cold. Maybe
this will become a good idea at some point, but that's going to be a
fair piece down the road, yet. Perhaps a year or two after Apple
abandons PPC support altogether, but can you imagine the flood of
tech support calls MS will be getting if they have parts of their
flagship product which are universal while other parts are
Intel-only? No, this would likely necessitate a complete Intel-only
release. Now, I don't have any idea at all what the actual numbers
are, but I would bet it's still less than 50% of MS Office users who
have migrated to Intel Macs, and it's just poor business to kill 50%
of your potential market right out of the starting gate. Also, I'm
certain there are many lab environments, like my own little library
here, that are mixed groups of machines. That could potentially be a
terrible support issue; difficult to explain to most users why they
can't open their Mac Access file on the Mac they're using today even
though they just created it yesterday two seats down.

Nah, no good.

Greg Sigman

Hank Harken wrote:
> David Ross speculated and pondered...
>
>> Now on the flip side, MS Access has never made it to the Mac supposedly
>> due to much of the core code being written in x86 assembly. And this
>> would be a VERY understandable reason. But now that Apple is x86, I
>> wonder what reason might be given now as to why it will not be ported.
>
> IMHO, the appearance of MS-Access was due to the release and success of
> Filemaker for MS-Windows. FM became the best selling database program
> for Windows. I believe MS developed Access and added it to MS-Office for
> Windows to keep the competition from getting the entire market. A
> strategy not too far from giving away Navigator to crush Netscape. When
> IT folks are asked for a db recommendation they only need to point at
> the MS-Office package. Interestingly, some people have referred to
> Access as the world's most widely distributed unused application. FM
> repeatedly receives the highest ranking and "Editors' Choice" awards for
> MS-Windows DB programs in PC Magazine.
>
While both programs have the adherents, MS Access has the ability to live in the enterprise much more easily than FM. And it has a programming model that is more flexible. I've seen a LOT of FM things that do nice things. But they all seem to stall at some point as the complexity of the FM model for large complex applications comes to bite them.

And there are WAY more useful Access trinkets and small apps out there than for for FM. I've looked several times for people.

David

Gregory Sigman wrote:
>> Now on the flip side, MS Access has never made it to the Mac
>> supposedly due to much of the core code being written in x86
>> assembly. And this would be a VERY understandable reason. But now
>> that Apple is x86, I wonder what reason might be given now as to why
>> it will not be ported.
>
> Here's one good one I can think of: the current installed base of
> millions of PPC Mac-owning Microsoft Office customers. Don't forget
> the PPC half of 'Universal Binary'.
>
>>
>> And to be honest I wonder how much a new version VBA for the Mac
>> office could be lifted (with some non trivial effort I suspect) from
>> the windows side.
>
> Same thing- you're still leaving the PPC base out in the cold. Maybe
> this will become a good idea at some point, but that's going to be a
> fair piece down the road, yet. Perhaps a year or two after Apple
> abandons PPC support altogether, but can you imagine the flood of
> tech support calls MS will be getting if they have parts of their
> flagship product which are universal while other parts are
> Intel-only? No, this would likely necessitate a complete Intel-only
> release. Now, I don't have any idea at all what the actual numbers
> are, but I would bet it's still less than 50% of MS Office users who
> have migrated to Intel Macs, and it's just poor business to kill 50%
> of your potential market right out of the starting gate. Also, I'm
> certain there are many lab environments, like my own little library
> here, that are mixed groups of machines. That could potentially be a
> terrible support issue; difficult to explain to most users why they
> can't open their Mac Access file on the Mac they're using today even
> though they just created it yesterday two seats down.

I disagree. But then again I live in an environment where the business seat that do NOT upgrade every 4 years at a minimum are at a terrible competitive disadvantage. Architecture and CAD.

David Ross