Re: Danny's Corporate Roadmap

From: ian (nospam_at_nowhere.com)
Date: 09/16/04 

Date: Wed, 15 Sep 2004 23:17:11 +0100

Danny,

Thanks for the considered reply - MUCH appreciated, at what I guess is a
fairly busy time for you <g>.

> >
> > When Danny said 'roadmap' I was hoping for Borland to lay out a clear
> > path for the next few years, with projects, milestones,
> > schedules...you know, the sort of thing that roadmaps usually
> > include.
>
> Well, we could give you pie in the sky dates that are guaranteed to e
> wrong, but I rather think you'd be more interested in what sort of
> functionality we're working toward.

I didn't expect dates, more a general outline: 'Q3', '2005', '3 months after
Whidbey' etc (though I have sympathy for you when people whine about outline
plans/dates changing)

> In the Delphi camp, the roadmap has been shown and discussed in nearly
> every Delphi session this week, over and over again: Diamondback is
> the next release of the Delphi tool chain. We plan to release Delphi
> tools with support for .NET 2.0 Framework (Whidbey) in 2005, shortly
> after the release of .NET 2.0 itself. We have long-term research
> projects in mind for the Longhorn time frame. Given the long window
> for Longhorn, it's likely we can turn around two releases of Delphi for
> the .NET 2.0 platform before Longhorn arrives.
>
> Nothing magical in all that, if you're aware of what the platform
> calendar looks like. No dates either. ;>

Now you're getting the hang of it <g>

Any reason why the rough timescale for the SDO developments can't get a
similar outline, or is it just too soon/confidential?

>
> Maybe even a mention of WTF is happening to BCB - though
> > that's probably asking too much :-(.
> >
> > Not a holistic process umbrella.
> > Not even a 64-bit holistic process umbrella.
> >
> > I have been a lone Delphi developer since v1. I'm looking for future
> > versions of Delphi to include cool stuff to make my life easier:
> > version control, unit testing, bug tracking, deployment control etc,
> > as part of the whole ALM deal, and the story so far on Diamondback is
> > encouraging - in fact, much better than I was expecting, given the
> > recent record of delivery by Borland - but I can not see ANYTHING
> > here for me.
>
> Well, that's where we on the Borland product team have our work cut out
> for us. ALM and the larger SDO vision won't work unless we can make it
> relevant to the developer. Workflow and process documentation might
> not be as critical to an individual developer as to a 100 person team
> scattered across 4 continents, but that doesn't mean that workflow and
> process management are completely unimportant to an individual.

Delivering that message will be key. The current ALM vision is one thing
(that I have yet to fully buy into: I need to write the code so that I can
figure out the pretty diagrams <g>), but some of the things outlined I will
need convincing about.

> We hope to make these "process-scale" information ecosystems
> interesting and useful to individuals. The cardinal rule is they
> should not get in the way of your coding - they should simply feed on
> the operations you're already doing. In a team environment, each
> developer's IDE is a neuron in the larger project sensory network.

A neat trick if you can do it. I see the benefit for the big guys, who
should be sitting up and taking notice in a big way: but I'm the whole brain
(and occasionally some less useful organs) in my network. I will be
impressed if you achieve seamless flow, in a modular fashion - and let me
buy only the modules that I'm interested in. I will not shell out major
money for something I will only use a fraction of.

> >
> > To quote a bit more, the above list of areas is seen as part of
> > 'defining the rules of engagement', an attempt to 'create a market
> > segment we can define, own and win'. 'Instead of bludgeoning it out
> > on the home turf of a much larger opponent, find a way to define your
> > own home turf in which the opponent is ill equipped to respond'.
> >
> > Is the long-term strategy to concede defeat to Micro^H^H^H^H^H a 'much
> > larger opponent' in the developer tools market segment?
>
> Nope. It's called changing the playing field to take advantage of your
> own strengths and their weaknesses. For example, Delphi 1.0 changed
> the playing field of compiled application development by combining a
> fast compiler, visual app design tools, and strong database access into
> one product, in one coherent application architecture. That was a
> radical (and scary) change from the norm for compiler tools of the day.
> It wasn't enough for Turbo Pascal to compete solely as a fast compiler.
> There were other compiler tools, and there were GUI designers, and
> there were database libraries, but nothing brought them all together.
> Until Delphi.

You're preaching to the choir <g>. And it didn't scare me a bit - I shelled
out my own cash, and spent the next decade building a business around it.
The attraction for me was instantaneous: I just 'got it'. I am not sure that
you will get the same immediate 'OMG: I MUST HAVE THIS' with a set of
workflow tools: your strategy for building a buzz around this will be
interesting to see.

>
> > Are the core
> > development tools going to take a back seat to the development of
> > this 'new home turf'?
>
> Nope. The core development tools are the entry points to creating that
> home turf. A software development process management system that is
> not seamlessly and silently connected to the developers' daily activity
> is a system with nothing to report. The core development tools'
> participation in the larger info ecosystem give the engineering team
> greater visibility and participation in upper management's macro
> decisions. It gives the developers documented ammunition to justify
> why management's latest proposal to pull the schedule in by 3 months
> would have disasterous consequences on the product feature set and/or
> quality, and how adding additional people might solve certain "long
> poles" in the schedule but not others, and so forth.
>
> One side of SDO is to provide management with better information about
> how their business is doing. The flip side is that the better info
> that management is seeing should mean that management is more informed
> of engineering's needs, abilities, and objectives. I know I would
> certainly like for my management to have a better understanding of the
> dynamics surrounding the products we work on (with less effort on my
> part)... ;>

You need to manage your management a bit better <g> I just tell mine what
they can have, and when - the rest is up to me ;->

> > Can we expect a return to huge gaps between
> > product release and bug fixes?
>
> Absolutely not. The long-term vision will take several product
> releases to fully realize. We started on ALM more than two years ago.
> Now that we're starting to realize much of that plan, it's time to push
> out the vision even further. Software Delivery Optimization is ALM
> taken to the next level.

ISTM that this is absolutely vital: a commitment to quality, with visible
results, is a MUST for most companies, but for a development tool provider
it is fundamental.

> > Is this the stuff that Danny + all the
> > other key guys are going to be focussing on?
>
> Exclusive focus? No. Working on as needed? Yes.
>
> >
> > Is the corporate roadmap supposed to make your existing customers
> > think you're not in their target market any more?
>
> Nope. We just have to demonstrate that the big roadmap also applies to
> the little guy. ;>

I hope you can. I think it is a bold vision, which I completely understand:
as long as it does not interfere with the delivery of the fundamental
products.

Once again, thanks for the reply - I feel a lot happier knowing that the
little guy is still part of your plan. Let's hope it works out well for both
of us.

Enjoy the rest of BorCon,

Cheers

Ian

Relevant Pages

  • Re: Dannys Corporate Roadmap
    ... In the Delphi camp, the roadmap has been shown and discussed in nearly ... radical change from the norm for compiler tools of the day. ... The core development tools are the entry points to creating that ...
    (borland.public.delphi.non-technical)
  • Re: A Tale of Two Memory Managers (long)
    ... > horizon is Delphi for .NET and they feel that it will not be performant ... > memory managers. ... > Management. ... > Delphi Compiler in one thread.... ...
    (borland.public.delphi.non-technical)
  • Re: Yet Another Arnold Article
    ... >> the case if the development tools were viewed as of strategic ... > shareholders to do so in order to maximize shareholder value. ... all; I'm a Delphi user. ... I had a discussion here with Danny when SDO was unveiled, ...
    (borland.public.delphi.non-technical)
  • Re: Diamondback new features for Win32
    ... gotta notify the newbies of what isn't coming... ... wouldn't, and what's keeping me now with Delphi is existing code, period. ... .Net is a MS compiler technology for as long as Mono isn't up to speed ... > development tools and they still produce excellent development tools. ...
    (borland.public.delphi.non-technical)
  • Re: Are we kidding ourselves?
    ... Win32 apps, partly because we got trapped by some third-party components ... AJAX can be done for Delphi for .NET today. ... :) Development tools and their vendors are ...
    (borland.public.delphi.non-technical)