(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.
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.
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 allthisstuffI’vebeenbloggingaboutsincethe conferencestarted. 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…)
“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)
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
The code is there as a hint, not very important. These are design patterns, not code patterns.
Goals of Patterns
Many patterns promote loose coupling -> more flexibility
“Think before you code” approach
Pattern names are very relevant
RAD shines but…
As apps grow, you need a better infrastructure, not just the plain VCL
Create a new object of the same kind of another object you have at hand
In Delphi you can implement a Prototype using:
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)
Create a new instance, then AStream.ReadComponentRes(C); (but if both have the same owner, watch out for Name collisions)
RegisterClass[es] the classes you’re going to use
Then you can write a Clone method
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?
Data in unit causes some trouble
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
Descend from visual controls, so you can add e.g. “Text” and “Value” properties tomultiple 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.)
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
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?
The new “for..in” loop is an out-of-the-box implementation of the Iterator 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.
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?)
E-mail notifications (customize per group); registered interest
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
Impact of change
Important Agile Traces
External files (might be a bad idea in Agile, since the files might change frequently)
External revision control system?
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
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 is an agile software process that reflects some of the practices used within Microsoft.
Agile Software Development
Team model is the most critical piece of the agile software development process. If you know it, you can answer 90% of the questions.
The “Agile” Pattern
Incremental Threat Modeling
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
Increased Customer Involvement
You’d think success would depend on some new server technology or something, but customer involvement seems more important
Working software over comprehensive documentation
Customer collaboration over contract negotiation
An agile method is
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.
Business Analyst (handles interaction with customer)
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)
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”
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
Willingness to Learn
Get Specific Early
Qualities of Service
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.
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?
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
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.
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.
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
No Severity 1s and 2s in the shipping product
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.
Incorrect handling of boundary conditions
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
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.
Test Thresholds Evaluated
Risks Identified and Mitigated
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
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
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…)
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
Deliver early and often
More time up front
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.
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:
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 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 , 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
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
Minimizing risk, maximizing predictability
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
Where the business meets engineering
Get requirements out of low-fidelity text, and into visual media