Danny’s departure

Marco Cantù reported some sad news yesterday: Danny Thorpe has left Borland.

(Looks like it’s not just a rumor — John Kaster posted this on the newsgroups, which is enough confirmation for me.)

On the plus side, Danny’s new job is at Google, and it sounds like he’ll mostly be working on the FireFox browser — so we can certainly expect some even better things from FireFox in the future. (There have been rumors of FireFox extensions written in Delphi…)

So long, Danny, and thanks for all the tea leaves. Good luck — and, on a slightly selfish note, I hope we’ll all benefit from your new job as much as we did from your old one.

So is disavowal going to become an annual ritual?


Anybody remember a little flap last year, over the beta license agreement for Diamondback?

Well, apparently nobody at Borland remembers it, because nobody actually fixed it. From section 6 of this year’s beta license agreement:

6. CONFIDENTIALITY. You acknowledge that the Product including its existence and features, and related information remains a confidential trade secret of Borland. You agree to hold this information in confidence, not disclose it to any person, and not use it for any purpose other than the use and operation of the Product as permitted under this License.

Look familiar?

Now, you know I’m going to install it anyway; you know us geeks and our toys. But think I’m allowed to be a little grumpy about it. Didn’t they fix this once already?

So anyway. By the time you read this, I will grumpily deny that I know anything about a new version of Delphi that might or might not be coming out. I don’t know anything about all this stuff I’ve been blogging about since the conference started. As far as I know, Borland isn’t coming out with another version of Delphi this year. And no, that isn’t a DVD in my pocket; I’m just happy to see you.

In fact, I have no idea why I just wrote this post. I don’t know anything about it.

(Unless, by chance, Mr. Swindell wants to fix it again…)

Closing session

  • Started on Tuesday with a surprise: a new CEO
    • Developer guy
    • Loves developers
    • Told everyone developers rule the world
    • Video on BDN
  • Will put up JBuilder and Delphi demos as well
  • Tempo – IT management and governance
  • “Project Maia” – Requirements engineering: turning Word-based requirements into something developers can actually use
  • Getting the external forces under control
  • Spirit of Delphi award: nominated & voted on by Delphi development team to a member of the community who eats, breathes, sleeps and bleeds Delphi, is active in the community, newsgroups, magazine articles, supermarkets.
    • This year: Pierre le Riche (developer of the FastMM memory manager)
  • Borland Developer Network (launched as beta in 1999 – still beta)
  • GetPublished
  • Conference proceedings online – http://bdn.borland.com/devcon05

Delphi Design Patterns

Delphi Design Patterns

Marco Cantù


We have some interesting IDE builds floating around… Marco’s title bar says “Borland Developer Studio 2010”. At one point when he was having some problems with the IDE, he said, “Well, it’s an early beta.”


  • What is a pattern?
  • Sample GoF patterns
    • Implemented with some creativity
    • Applied to “everyday visual” code
  • Delphi 2006 and patterns

Goals of this talk

  • Overview of patterns in OOP
  • Explore a number of classic patterns from the GoF book
    • from the Delphi language perspective (which matters – some of the creational patterns, for example, aren’t necessary in Delphi)
    • providing some implementation samples

What are patterns?

  • Capture similarities in repeated building blocks: design solutions, not actual code
  • GoF book
  • Pattern layout: name, problem, solution, consequences
    • The code is there as a hint, not very important. These are design patterns, not code patterns.

Goals of Patterns

  • Better OOP
    • Many patterns promote loose coupling -> more flexibility
    • “Think before you code” approach
  • Better communication
    • Pattern names are very relevant
  • RAD shines but…
    • As apps grow, you need a better infrastructure, not just the plain VCL

Prototype pattern

  • Create a new object of the same kind of another object you have at hand
  • In Delphi you can implement a Prototype using:
    • Class references
      • If you don’t need to copy the data, you can just do Object.ClassType.Create
      • If you want to call the right virtual constructor, you need to cast: TComponentClass(C.ClassType).Create(C.Owner)
    • Streaming
      • AStream.WriteComponentRes(C.Name, C);
      • Create a new instance, then AStream.ReadComponentRes(C); (but if both have the same owner, watch out for Name collisions)
    • RTTI
      • RegisterClass[es] the classes you’re going to use
      • Then you can write a Clone method

Singleton pattern

  • Only one instance of a class
  • Very simple pattern, but very tricky to implement
    • Needs a specific setup mechanism
      • Or can you use a constructor as well?
    • Consider subclasses
      • Data in unit causes some trouble

Adapter pattern

  • Convert the interface of a class into another expected by the user of the class
  • Better than “if X is…”
  • Can be nicely implemented using interfaces
  • Examples:
    • Descend from visual controls, so you can add e.g. “Text” and “Value” properties to  multiple different controls.
    • Interposer class: descendant class that has the same name as the base class. Interesting way to force the runtime to create *your* TButton instead of the standard TButton. Yikes. (Seems like that would be really brittle! The compiler wouldn’t even tell you if you got it wrong.) (It would also be problematic in .NET, if both are in the same namespace.)

Façade pattern

  • Provide a simpler, higher-level interface to a set of interfaces in a subsystem, making it simpler to use and promoting weak coupling
  • In Delphi: a single interface for a collection of components hosted by a container (e.g., providing access to the field values of a dataset on a data module)
  • Shield you from the other guy’s implementation details (at least a little)


  • Replace a series of many objects with a single stateless one, with status information provided on method invocation: pretend you’ve created 10,000 of something
  • The DbCtrlGrid is the perfect example. It looks like it’s got many editors, but in reality it’s only got two

Proxy pattern (Marco writes it as “proxi”)

  • Provide a surrogate (placeholder) for an object (delaying creation cost, if any)
  • Delphi uses something like this for form handles, different reason (that reason being Windows 9x)
  • At design time, a proxy is created for the form you’re editing
  • Proxy components as “light” representations of components (e.g., a database table). Increases total memory usage if you do need to create everything, but decreases time and memory if you don’t.
  • Proxies in OPF frameworks
    • Lightweight objects with few DB columns

Iterator pattern

  • Provide a way to access the elements of an aggregate object sequentially, without exposing its underlying representation
  • Often used with container classes
  • Are iterators better than for loops on VCL lists?
    • Probably
    • The new “for..in” loop is an out-of-the-box implementation of the Iterator pattern

Observer pattern

  • Define a one-to-many dependency between objects, so that when one object changes state, all its dependents are notified of this
  • One of Marco’s favorites, found in the VCL
    • Notification and notification subscription
    • DataSource (a broker that sits between the two ends, and manages the notifications)
    • Actions (I don’t think these are really Observer, since they’re “pull” rather than “push”)
  • Example: a MultiCast event handler
    • Eww, his “MultiClick” is a write-only property. Worse, setting it doesn’t replace the old value of the property – it accumulates. And magically ignores duplicates. None of which is intention-revealing. Very smelly code.
  • A “Real” Observer: demo

Delphi 2006 and Patterns

  • Available with Together support
  • GoF patterns implementations
  • Extensible with your own patterns

Miscellaneous conference catch-up stuff

I guess I haven’t blogged about Tuesday evening’s Meet the Team session yet. Last year, they did a presentation where each of the devs showed off their favorite new feature. They didn’t do that this year, which was kind of a bummer. All they did was have people standing around, near signs with the product names on them, and people could wander up and talk to them. I got involved in, or listened to, a few interesting discussions about everything from comment spam to the number of bugs Danny has fixed (and created). Not bad. They didn’t hand out any betas, though.

This afternoon, I was hoping to go to Chris Bensen’s talk on “C++ and .NET Interoperability”. Unfortunately, that session got canceled. 🙁 We’re not a C++ shop, but we have a large Win32 codebase that we’re looking at moving to .NET, and that move would most likely be done piecemeal, so interop is very much of interest. The description said the session would cover (among other things) mixing the VCL, VCL for .NET, and WinForms frameworks. Man. I was looking forward to that one.

I went to the computer lab this morning and played around with Delphi 2006. I’m liking the new features, especially the edit-completion stuff. I poked around briefly with modifying the existing templates, and was able to fix the template I complained about yesterday. Haven’t tried creating my own template, because it isn’t immediately obvious what all you can do in that XML file, and there’s nothing about it in the Help file yet.

On an amusing note, the IDE seemed quite responsive in the lab, and I found out why when I looked at the System properties… that computer-lab machine had three and a half gigs of RAM! (Please can I have some?)

Empowering Agile Development with CaliberRM

Empowering Agile Development with CaliberRM

Jerry Odenwelder


Test-first speaking 🙂 (they had to troubleshoot and test the recording software before the session started)


Likes agile – customer involvement, lots of testing


  • Individuals and Interaction: People are not pluggable units
  • Customer Collaboration: Customers are ultimate beneficiaries, so need to be involved
  • Working Software: is what adds value to the business
  • Adaptive: Change the process as needed.

Agile Requirements

  • User Stories
    • Can break down into one or many requirements
  • Describes a unit of work that contributes to business value
  • Created by, and owned by, the customer
  • Meets the PET criteria
    • Can be Prioritized
    • Can be Estimated
    • Can be and Tested

Why Use a Tool (instead of index cards)

  • Automation (cut/paste)
  • Disaster recovery
  • Reporting
  • Traceability
  • Distributed Development
  • Scalability
  • Customer is not available

CaliberRM Supporting Agile

  • Light Weight
    • Expert Client
    • Cross-Platform / Web Client
  • Works in your environment (Delphi, etc.)
  • Get the bureaucracy off your back
    • Document generation
    • Reporting
  • Everyone is on the same page
    • Central server

Managing User Stories

  • Rich text editor
  • Attach pictures
    • Take a picture of the napkin and put it in as a requirement
    • No zooming support in the current version
  • Embedded tables (e.g., Fitness)
  • Glossaries: business can write terms they’re familiar with, they’ll automatically be highlighted in the text, and when the programmer hovers over them, they find out what the acronym means
  • Could create a requirement type of “Backlog” and another called “Sprint Backlog”
  • User-defined attributes, e.g., complexity, iteration, requires spike


  • E-mail notifications (customize per group); registered interest
  • Threaded discussions
    • Record hallway discussions
    • If the customer isn’t immediately available, could post questions and get responses back
    • When you log into Caliber, you get a pop-up notification (can disable, can run explicitly later) showing which discussion items you haven’t read yet

Decrease time of meetings

  • Filtering: Remove data from grid that’s not important for this meeting; sort
    • Can save the grid settings and reload them later
  • Edit right there during the meeting

Maintains history of changes

  • Records how requirements change over time
  • Go back and review old version of requirements
  • Document Factory can produce documentation (which even includes the picture of the napkin)
  • History tab: top pane shows history of changes, bottom pane shows what changed in any particular rev
  • No way to require (at the server side) comments for each change

Manage Dependencies

  • Valuable for
    • Impact of change
    • Risk assessment
    • Planning
  • Important Agile Traces
    • Dependent requirements
    • Project tasks
    • Model components
    • Validation procedures
  • Tracing to
    • External files (might be a bad idea in Agile, since the files might change frequently)
      • External revision control system?
    • TestDirector
    • StarTeam
  • View trace matrix
  • When you change one item, the items it feeds into are marked as suspect, so you can go and review them


  • Isolate requirements for a release or iteration
  • Once a requirement has been put into a baseline, it can’t be modified through normal editing (you have to explicitly go into Baseline Maintenance)
  • Baselines support digital signatures (if you have compliance issues)
  • Once a baseline is locked (signed), it can’t be unlocked (for compliance reasons)
  • Can diff two baselines, or current baseline with old baseline


  • Supported to User-Defined Attribute level
  • Q: If you’re in an agile environment, do you need security? A: It might not be a bad idea to keep the customer from editing the estimates (grin). Maybe the developer shouldn’t be able to edit descriptions or iteration numbers. And if you’re working with a third-party vendor, you’d want to rein that in as well. The person who drives the meetings should probably have all access.


  • Change is inevitable; embrace it
  • Requirement Capture and Understanding
  • Planning and Risk Analysis
  • Tracking Progress
  • Post Mortems

Q: What happens if you have an unreliable network connection that dies while you’re working? A: Anything they were working on, but hadn’t saved yet, will be lost. The requirement they were editing will be locked until the session times out (or the admin logs off their session).


Q: How do you make sure the story gets QA’ed and documented? A: You would probably want to use user-defined attributes for that (possibly in combination with the built-in Status and Priority attributes). Find them by setting filters on the requirements grid.

MSF for Agile Software Development

MSF for Agile Software Development

Granville Miller (aka Randy Miller)


MSF is an agile software process that reflects some of the practices used within Microsoft.



  • Agile Software Development
  • Team Model
    • Team model is the most critical piece of the agile software development process. If you know it, you can answer 90% of the questions.
  • Personas/Scenarios
  • The “Agile” Pattern
  • Shadow Applications
  • Incremental Threat Modeling
  • Context-Driven Testing
  • Risk

Randy usually gives people about a day’s worth of presentation on this stuff, and we’re trying to cover it in an hour, so this will be much abbreviated. There’s much more info available on Microsoft’s Web site (see link, below).


Project Success is Rare

  • 2004: 15% failed, 51% challenged, 34% succeeded
  • 2000: 23% failed, 49% challenged, 28% succeeded
  • 1995: 40% failed, 33% challenged, 27% succeeded
  • 1994: 31% failed, 53% challenged, 16% succeeded
  • The good news: State is Improving
    • Small Releases
    • Increased Customer Involvement
    • You’d think success would depend on some new server technology or something, but customer involvement seems more important
  • Agile Manifesto
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
  • An agile method is
    • Iterative
    • Incremental
    • Self-organizing and
    • Emergent.
    • It must include the attributes; otherwise it is a “lightened defined process”.

Activities in MSF

  • There are more roles than just customer and developer. There are architects, testers, etc., who add value.
    • More roles -> communication complexity increases.
  • Composed of 14 basic work streams
    • Basic activity building blocks of MSF
    • A work stream is an activity that is composed of other activities
    • Activities are described using the ETVX format (whatever that is)
    • Contains 70 activities (not including work streams)
    • Most work streams are performed by a single role
  • Roles <-> Constituencies
    • Team of Peers
    • Business analyst: Product management
      • is responsible for two constituency groups: one is the sponsor, the other is the users.
      • is responsible for tracking time.
  • Release manager: in charge of understanding deployment, handing it off. Product manager: responsible for tracking budget and such. They can be combined.
  • Roles
    • Developer
    • Project Manager
    • Business Analyst (handles interaction with customer)
    • Architect
    • Tester
    • Release Manager
  • Work Streams / Goals
    • Capture Product Vision (business analyst)
    • Create a Scenario
    • Create a Quality of Service Requirement
    • Plan an Iteration (project manager)
    • Create Solution Architecture (architect)
    • Implement a Development Task (developer)
    • Build a Product
    • Test a Scenario
    • Test a Quality of Service Requirement
    • Fix a Bug
    • Close a Bug (tester)
    • Release a Product
    • Guide Project (project manager)
    • Guide Iteration (project manager)

Safe Harbor Statement

  • Choose the MSF for Agile Software Development process for projects with results-oriented teams who can work without lots of intermediate documentation
  • “Stretch to Fit” instead of “Shrink to Fit”
    • Minimalist approach
    • Agile methodologies promote adaptation

Scaling to All Project Sizes

  • There’s a matrix for whether it’s a good fit to combine particular roles
    • (P)ossible, (U)nlikely, (N)ot recommended
  • “If you have the skills to play a role, you may play that role”
  • Smallest project size is 3 people (with one or two people, you probably don’t need much process)


  • More than a set of activities – a collection of values
  • Quality is Defined by Customer
  • Pride of Workmanship
  • Team of Peers
  • Frequent Delivery
  • Willingness to Learn
  • Get Specific Early
  • Qualities of Service
  • Citizenship
  • Different roles. Some care only about time. Some don’t care so much about time, and fight for quality. Who breaks deadlocks?


  • There are many events that may befall a project that are not covered by our process
  • Use best judgment and adapt based on mindsets and principles


  • Descriptions of a group of typical users
  • Persona represents a “proxy” for the user group, and provides a means to talk and reason about the group through the characteristics of one fictional individual
  • On-site customer is the best you could hope for.
  • Actors in use cases: the other extreme. A developer is a developer.
  • Persona: fictional representations of people.
    • Be respectful.
      • Best Buy did a set of personae for their customers. One was the “Devil Customer”. This was fine until it landed in the Wall Street Journal.
    • Can represent the novice and the advanced developer.
    • Scenarios associated with each persona.
    • Knowledge, skill, usage pattern
  • Can still meet actual customers (and refine our personae).
  • Different people come up with different personae, write them on sticky notes, put them on the board. When you take yours up, you decide whether it should be combined with one of the others, or should be separate.
  • Q: Where do you get pictures to use for your personae? A: Got any artists in your group? Can you buy a CD of stock photography?
  • Baseball cards of personae (including organizations)
  • When you’re trying to make a decision, at least you have a clue.


  • Role: Online shopper
  • Motivation: Get it quick
  • Usage pattern: Hates shopping but wants to get it quick. …

Incremental approach – Why scenarios over use cases?

  • Risk reduction
    • Changes
    • Delivery
    • Progress
  • Activities need to be able to handle small increments up to a single change
  • A scenario is basically a single path through a use case. Easy to break into smaller increments if needed.

The Agile Pattern

  • Scenario list (aka backlog) -> iteration plan
  • Peel off pieces, add them to a particular iteration
  • The things in the list aren’t actually scenarios – they’re reminders. The business analyst writes them up for the iteration.

Date or Feature Driven

  • Which?
  • Parkinson’s Law: If you give developers more time, they will find ways to fill that time. So you have to be aggressive on the date, right?
  • But not everything is really date-driven
  • “We’re going to deliver in March, even if it’s March 51st”

Minimum Acceptance Level

  • If you ask customers what they want, they’ll list off the Exciters & Delighters. (What do you want in your TV? Remote control, stereo, closed captioning, etc.)
  • But they usually won’t tell you about the Dissatisfiers (must-have requirements) (ability to turn the TV on without the remote, good picture quality, etc.)
  • First few iterations: you work mostly on the dissatisfiers, and a little on the exciters. But you can’t deliver until you make enough progress on the dissatisfiers.
  • So even if time ran out on iteration 3, you still couldn’t ship.
    • Of course, this is all pragmatic. Depends on market. If you really want to be first-to-market, you might ship anyway.
  • Even if you’re date-driven, you might not really be date-driven, because you might not be able to ship without X features.

Feature graphs:

  • Active (until the developer finishes it – doesn’t distinguish ones that haven’t yet been given to the developers to work on)
  • Resolved (goes to test: implemented fully)
  • Closed (tester can run it totally through)
  • Do a stacked area graph over time. Active=red, resolved=yellow, closed=green.
  • If you’ve still got too much red as of the ship date, the project manager and the business analyst have a problem, and need to start talking to each other.
  • If the yellow keeps growing over time, it could mean you don’t have enough testers, or that scheduling is poor (finishing too many items at once), or the test cases are failing (coders are submitting bad code and marking it as resolved, and the testers have to kick it back), or management is putting too much pressure on and the team stops caring about actual quality and becomes totally dysfunctional.

Context-Driven School

  • Value of any practice depends on its context
  • If you absolutely *must* ship by a certain date or the company runs out of money, you might be incented to ship something that’s not ready. Is that the right thing to do? It depends on how the market reacts.
  • There are good practices in context, but there are no best practices
  • People, working together, are the most important part of any project’s context.

Context Driven Approach

  • Testing that is acceptable on opne project may be criminal on another
  • Define shipping criteria based on what’s important to us
  • Release criteria
    • No Severity 1s and 2s in the shipping product
  • Testing thresholds
    • Code Coverage for Unit Test
    • Getting 60% code coverage is really normal
    • To get 80%, you start using things like mock objects, and it gets harder
    • To get 95%-100%, you start building scaffolding and bizarre stuff
    • What’s right? Answer: it depends entirely on the project.
  • Focusing on statement and branch coverage is not sufficient.
    • Missing code
    • Incorrect handling of boundary conditions
    • Timing problems
    • Memory leaks

Bug debt

  • If the developer has more than 30 bugs, it’s time to schedule a bugfix iteration, where you fix bugs (and fix bugs only)
  • Worth doing even though you take a hit on velocity, because you’ll take a hit on velocity anyway (because you either fix them as you go, or they slow down your coding or testing)

Conduct Exploratory Testing (One Heuristic)

  • Assume a persona
  • Time-box
  • Traverse the system looking for new goals, roadblocks, or improvements, keeping the needs of the persona in mind
  • Add any new bugs, scenarios, or quality of service requirements discovered using this process

Risk and Agile Processes

  • Agile processes drive out risk through short release cycles and customer feedback.
    • Requirements risk
    • Implementation risk
    • Quality risk


  • Objectives Reviewed
  • Progress Assessed
  • Test Thresholds Evaluated
  • Risks Identified and Mitigated
  • Deployment Ready

Methods of Adoption

  • Organization / Team
  • Grassroots – individuals find the practices useful and the process spreads by providing value
  • MSF provides friction-free usage that doesn’t get in the way

More info

  • http://www.microsoft.com/msf – download “MSF for Agile Software Development (Process Guidance Only)”; has much more info than this presentation
  • Will be released in book form – MS wants to ship it with Team Foundation 1Q next year

Agile Methods with Borland

Birds of a Feather: Agile Methods with Borland

Matt Gelbwaks – Borland


This was pretty much exclusively done as a Q&A session. We came up with questions up front, and then they tried to answer as many as they could.


Note: All the questions we ask during this session are going to become requirements and scenarios in Borland’s feature backlog. Cool!


Interesting idea: show a scatter graph of estimated vs. actual time for each story. Hopefully that scatter graph will get closer and closer to a 45-degree line over time.


If we have ideas for new information radiators we’d like to see, tell Borland, or e-mail an example to Dan Massey. That’s dmassey, on the obvious domain name.


What’s Borland’s experience with agile?

  • Borland was doing agile before there was agile: in 1992, they were already doing short iterations, etc.
  • Today, some teams are doing formal Scrum with StarTeam
  • Larger projects: “release train” (like Eclipse – I’m not sure exactly what that means…)
    • 6-week milestones
    • Some teams do smaller iterations within that
    • All requirements in CaliberRM
    • All bugs in StarTeam
    • Starting to use Tempo
  • Many of Borland’s larger clients have SarbOx requirements, and have audit requirements. Need to prove that the work is being done the way it’s supposed to be done (so some developers need to spend their time auditing instead of developing). To really do agile, they probably need to automate that.

How do we capture key design decisions in Together?

  • e.g., how do you capture the alternatives that were considered?
    • Consider: Instead of making a decision, hold off as long as possible, to show you’re thinking about it. Include all three options in the diagram, label them somehow. As you figure out what will drive the decision, you can keep notes. (last responsible moment)
    • Keep track of the set of options that are available. Don’t collapse them into an actual decision until the iteration where you depend on that decision.
  • There are some feature requests that might cover this…
  • Short-term: using a Description field to record those decisions; whenever a decision is made, it should have been a requirement, so roll that back into the requirements repository (so it may feed into other projects)
  • Could use version control to store the history of the discussion (StarTeam’s threaded discussions).
  • Use linkages between tools (e.g., links into CaliberRM)

How do you reconcile informality of agile with formal communication?

  • Agile does require discipline, and a way to be measured.
  • Use the discussion feature in CaliberRM to record the hallway discussion you just had (and why).
  • You can’t necessarily capture those hallway conversations. But when you’re having an actual meeting, bring up the requirements grid and change it right there – don’t make notes and update the requirements later.
  • Give visibility to the time you spend on formal communication.
  • Problem with discussion feature: no way to find out whether there are open questions still hanging. Is the thread closed?

Selling agile to management

  • What’s the problem you’re trying to solve? Measure it and start improving: timeboxes, testing, etc.

What do you do when you can’t find someone with the time to play the role of customer?

  • Borland’s actual clients don’t have a body to send to Borland, so Borland uses full-time surrogates
  • If you can’t even get a full-time surrogate, try doing a big investment of time up-front, using Maya or some such
  • Then use tools like CaliberRM to keep the discussion going in trickle format
  • Three axes to address – people, process, technology
  • People
    • Deliver early and often
  • Process
    • More time up front
  • Technology
    • Radiators
    • Web context
  • Possiblity #1: If there is no customer who thinks it’s worth their time, there’s no agility – and the value of the project is zero. If management isn’t willing to make a person available to tell you whether you’re on the right track, there’s zero chance we’ll deliver what you need, and this whole project is wasted effort.
    • Maybe the person you’re delivering to isn’t really your customer. They might be your end user, but they’re not your customer.
    • Go ahead and deliver the wrong thing (which it will be, since nobody ever told you what they wanted), but deliver it with panache. If you get them mad at you, maybe they’ll take a little more interest. (Nice idea if this actually worked…)
  • Possibility #2: Sit down with customer and Maya, to elicit requirements. Deliver something tangible and viewable, quickly, that shows understanding. (Maya is coming out sometime next quarter) Or otherwise find a way to show value immediately.

Second Keynote

I didn’t live-blog during the keynote yesterday, because it was an hour and a half, and I figured I wouldn’t have enough battery. Since today’s was only an hour, I fired up the laptop. Here’s the goods:


Announcements (DavidI)

  • Product ordering to get conference discount: http://shop.discount.com/ or go to Programmers’ Paradise (same offer either way). International orders, pick up paper form.
  • Turn in conference evaluation form this afternoon by 3:00 to get a Borland Conference T-shirt. Sorta looks like a muted, monochrome Hawaiian shirt.
  • Tonight’s party is in the same room lunches are in. (Looks like they’ll have real food this year, too!)
  • Tomorrow, starting at 1:15, Marco giving “Fun Side of Delphi” session.
  • Borland’s SDO strategy: quick recap
  • Why being a developer sucks… even though we’re gods at what we do
  • So how is Borland helping control the madness?
  • Learn about the infrastructure being developed in order to enable the SDO vision
  • Partner testimonial, Accenture

SDO Strategy

  • Getting Good at Software – at the company level
  • Controlling the forces WITHIN AND AROUND a development organization
  • Being able to answer these questions:
    • Are you doing software right?
    • Are you doing the right software?
    • How do you know?

Getting good at software means:

  • Better targeting opportunities. Management needs to be making decisions based on the most important thing for the business.
  • Increase time-to-value of software
  • Improving quality
  • Minimizing risk, maximizing predictability
  • Reducing cost

SDO is about answering:

  • Are you doing software right, *as an organization*? Right amount of QA? Capturing requirements?
  • Are you doing the right software? Nothing pisses a developer off as much as when they get jerked around by management.
  • How do you know? Measure.

Controlling the forces…

  • …that impact a developer
    • Which projects get funded?
    • How much rigor goes into that decision-making process?
    • Which engineers get deployed? Skills, experience, availability
    • The physics of scope, schedule, resources
    • The impact of change…
    • Timeliness, fidelity, and accuracy of requirements (e.g., up-front requirements documents)
    • …and the list goes on.

Top reasons why it rocks, and why it sucks, to be a developer

  • Why it ROCKS:
    • 3. Never-ending constant supply of new technologies to learn and use – enjoyable
    • 2. You can realize your ideas and dreams without the burden of physical materials – empowering
    • 1. With every single non-trivial endeavor in the world today, software is on the critical path. You get to solve tough problems for the planet, and sometimes even change the world – seriously satisfying
  • Why it SUCKS:
    • 10. Research – never enough time for the “R” in R&D
    • 9. Technology – it changes faster than I can code for it. (You get to play with those betas, but they crash.)
    • 8. Process – often makes life harder, doesn’t guide me on what’s next
    • 7. Communication – difficult to bridge cultures, language, timezones
    • 6. Bugs – not hard to fix… hard to find and hard to track
    • 5. Outsourcing – thread of job getting “shipped overseas” (or to eastern Europe, if you’re Marco)
    • 4. Schedules – never enough time, impossible to estimate time/scope/risk
    • 3. Requirements – hard to track, never enough detaiol, becomes stale
    • 2. IT Managers: if they had brains they’d be dangerous – care about the bottom line, we care about the software
    • 1. Resources – never enough… and tradeoffs? what’s a tradeoff? How often do you have a conversation with management where they make a tradeoff?
    • All of this is out of your control.

SDO is helping to control external forces

  • E.g. Management decision making
    • Management tools tied to development reality
    • Rigor in decision making
    • Good information = better decision making
  • E.g. The Garbage-In/Garbage-Out problem
    • Good requirement fidelity = higher probability of getting it right
    • High-touch, VISUAL dialog with users: a good thing.


  • Tempo demo – wizard that asks the manager questions to nail down the requirements and importance
  • Requirements elicitation – draw flowcharts, create storyboards with photos of existing customers
    • Generates requirements, test cases, etc.
    • Shows current project status automatically, so you don’t need to spend time in status meetings or even manually updating status
  • “Requirement Elicitation”
    • Where the business meets engineering
    • Get requirements out of low-fidelity text, and into visual media
    • Higher fidelity = lower rework
    • Lower rework = happier developers
  • “Portfolio Management”
    • Buzzword alignment: “IT Governance”, “Project Portfolio Management”
    • Real-time, data-driven status
    • IT decision making with DATA
    • IT decision making with PROCESS and RIGOR
    • Better decision making = less churn
    • Less churn = happier developers
  • Getting external forces under control makes more productive, happier developers
  • Bridge the language gap between developers and management

Futures: Raaj Shinde, VP SDO Platform

Shape of things to come:

  • “Common metamodel”: Software process
    • Authoring
    • Orchestration
    • Monitoring
    • Guidance
  • Hooks for other vendors’ software, e.g. Rational, Subversion

Donald Gravlin, CTO, Accenture Healthcare Practice

  • Leading health care organization’s business needs
    • Spiraling costs are forcing healthcare to be more efficient
    • Consumer driven healthcare is driving real-time information demand from the “Quicken” generation (both consumers & physicians)
    • Regional health information networks require application interop &* collaboration – a $200B software opportunity
    • HCOs require IT resources to focus on new products & services
  • Pain points
    • Rework of legacy environment required to transition toa  SOA platform
    • Lack of governance of distriuted IT development and integration
    • Rapidly changing regulatory requirements & time/cost of getting it wrong
    • Poor visibility and predictability of software will cost lives
  • What Accenture likes about Borland’s direction
    • Borland gets what it takes to be world class developers
    • Acquisition of Tempo
    • Rapid development of elicitation technology
    • Investment in building a platform

3 things you need to remember

  • SDO is relevant to developers
  • Borland is committed to delivering SDO
  • We value you, our loyal customers