Cap the conference :) (Willem van den Ende)
Marc Evers and I were a bit buzzed… We hoped, this year, to start announcing agile open earlier (and, unlike last year, not keep repeating ‘we should get started’). Well, unlike last year, we didn’t keep repeating it. We just didn’t get round tuit…
So last week, we finally got together around a whiteboard, decided that we did want to hold it in June (like last year, and as we planned), but we didn’t have a location etc. and didn’t want to spend as much time as last year in sending out invoices, dealing with exceptions etc.
So, we decided to go with an affordable conference location and leave things like hotel, dinner out of the basic package. That means we can send out just one type of invoice - you come two days, or you don’t, and beside diet preferences there are no options. Well, you can of course volunteer (we got spontaneous offers for that. ) or sponsor. We also decided to cap the conference at just thirty participants, so we could go with the venue. One of the reasons being, we thought we can’t get that many participants in a month anyway… Surprise, surprise, sending out the invite to a couple of mailinglists, and we’ve already passed the twenty participants mark. And we have some sponsors as well (we didn’t expect many in this timeframe, so we’re pleasantly surprised. Now we have to make sponsor packages 
and facilitate the other volunteers so we can self-organize )
So, without much further ado, I’m proud to announce the next
Agile Open Europe 2008
will take place in Utrecht, NL on June 5th and 6th. A vibrant place to push the envelope and do business together. And yes, we will find Belgian Beer - one participant listed that as a dietary requirement ;) Looks like its’ going to be good fun again. See you there!
And if you ’still’ haven’t registered - there’s a handful of places left…
Save Your Job: wud u pls lern 2 rite so ppl can reed ezr? (Sammy Larbi)
NUnit 2.5 Alpha 2 Released (Charlie Pool)
With a European trip about to start, I decided to release a second Alpha so that the new stuff would get some visibility. I won’t be doing another release till late June, so please give this one a try.
As compared to 2.4, NUnit 2.5 has quite a lot:
- Data-driven tests using [TestCase] and [DataSource]
- Additional asserts and constraints, including inline exception tests.
- Parallel and distributed testing using pNUnit.
- Bundled addins, now including RowTest and CSUnitAddin.
For more info, see the release notes.
In addition, watch the NUnit mailing lists or this blog for info about other extensions as they are released for NUnit 2.5.
A Simple NUnit Usage Recipe (Charlie Pool)
Scott White has a blog about NUnit Best Practices. The approach may require adjustment on more complex projects, but it’s a very simple recipe for those starting out with NUnit.
Conscientious Uncertification (James Bach)
I’m thinking of having badges made which say “Conscientiously Uncertified.” It’s for those of us who want to resist the dumbing down of our craft by cynical consultants promoting bogus tester certification programs.
For me, when I see that someone is certified as CSTE, ISEB, ISTQB, or CSTQE, I immediately think “there goes someone who was bullied into compliance.”
Any suggestions for what the badge would say?
Here are some options:
- Conscientiously Uncertified
- Certification Objector
- Uncertifiable
- No Bullies
- Proud to Be Uncertified
I should have a logo made, so like-minded freedom fighters can post it on their blogs. By refusing to give in to the thugs of certification, a tester shows he can follow a more difficult and more admirable path: self-education and self-certification.
Side Note: There is one certification program coming along that looks worthwhile, to me: the AST BBST certification. It will be difficult to obtain, based on demanding online coursework. It will not claim to be anything more than a certification that the tester has successfully made it through the course(s). Some of it is already available through the AST. The rest is coming. So far, the courses are free to AST members.
I will probably not be able to get this certification (I’m too disruptive in class), but at least I helped create it.
Mythbusting - Collective Code Ownership (Mark Levison)
In researching "Are there weaknesses with Collective Code Ownership?" for a news item on InfoQ I was struck by the number of myths that get repeated around Collective Code Ownership. I thought it time to burst a few balloons.
A number of writers equated Collective Code Ownership (CCO) with "no ownership" or chaos. Yet nothing could be further from the truth. Let's revisit Martin Fowler's definition (he's a better writer than I):
Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. You can consider this as no code ownership, but it's advocate prefer the emphasis on the notion of ownership by a team as opposed to an individual.
Now its not easy to practice CCO and to make it work you need an agreed on set of coding/formatting standards. You also need to practice pair programming to help maintain the required discipline. But its not chaos.
Simon Lin mentions a team that shared a single version control account. I'm not sure where this myth commons from. CCO says that we all own the code and that we're all responsible for maintaining it but nothing is said about sharing the same account. I think that responsibility requires that we're accountable for what we change.
Ralf's Sudelbücher
argues that "Collective code ownership is limiting software quality", in a rather lengthy note from two years ago. His core argument appears to be that generalizing specialists can't know all of the domains that they need to code and so produce weaker code. The number of domains that a project might encompass has grown so large (ASP .NET, SQL, ADO, ...) that no one programmer on the team can command a knowledge of them all. On this last point we agree. However I don't think that means that team members who aren't specialists can't produce good quality, simple code in other problem domains. Simplicity is easy to appreciate no matter what the problem domain. In addition most new API's follow well established patterns for a lot of methods (i.e. open/close) that make it easier to pick up the basics. To solve the remainder of Ralf's problem: when coding in area where you don't know the speciality well either pair with the specialist or get them to review it after the fact. Effectively implementing Martin Fowler's Weak Code Ownership. At least this way we avoid the inevitable bottlenecks when we really on the point hats to do all the work.
One fact I'm coming to believe: to achieve the discipline required for CCO to work you need more than just common development standards. You also need to write most of your code using Pair Programming and Test Driven Development (at worst Test Minutes Afterward). Without these practices, consider using Weak Code Ownership where each module/package has an owner/evangelist who's role is to ensure that the conceptual integrity is not only maintained but explained to other team members.
Why Game AI Still Sucks (Sammy Larbi)
Behold, the power of Extract Method (Sammy Larbi)
Save Your Job: Don't be "the grumpy old code ogre" (Sammy Larbi)
Save Your Job: Don't be (Sammy Larbi)
What does age have to do with learning new ideas? (Sammy Larbi)
SwingHelper (Darren Hobbs)
One of the most common causes of sporadic bugs in swing applications is doing things on the wrong thread. Most common of these is when a thread that is not the Event Dispatch Thread does something that updates the gui. Its very easy to do accidentally as seemingly innocent operations done on a background thread can fire off event listeners and end up inside code it shouldn't as a result.
CheckThreadViolationRepaintManager from the SwingHelper project is a very useful class that can be easily plumbed into a Swing application to report any wayward threads getting into gui code.
Also from the same stable is the EventDispatchThreadHangMonitor which can report when the Event Dispatch Thread spends too long outside its main loop (which will result in a sluggish and unresponsive gui).
A View From Inside ISTQB/ISEB (James Bach)
Alan Richardson writes this commentary from inside one of the stupidest of the certification programs: the ISTQB (well, he says “ISEB”, but by all accounts, it’s being taken over by ISTQB stormtroopers).
Long ago I also tried to change a certification program from the inside. I also failed. Now I do my best to cultivate the community of people who rise above it. As Alan points out, rising above can be difficult, because of all the poor fools who’ve been duped into believing that an ISTQB tester certification actually means something important.
What such certification really means is that, in England, and several other countries, certain unscrupulous or plain ignorant consultants are able to hold the testing craft for ransom, and almost no one will call them to account. Some of the perpetrators know full well what they are doing, but many of them, I think, know so little about testing that they honestly don’t realize what harm they do to the industry.
– James
Common.Addins.Build : Addin Building Made Simple (Charlie Pool)
Let me start right out by saying: I know some of you won’t find this to be simpler - but it is! If you can’t bring yourself to install NAnt or work from the command line, then this isn’t for you. But if you can get past the initial hump - or if you’re already past it - then this is for you.
The hardest part about building - as opposed to writing - addins is getting the references right. Addin solutions in Visual Studio generally contain from three to five projects: the addin assembly, the assembly referenced from user tests, a unit test assembly, possibly a separate test fixture assembly for use by the tests and one or more samples. All of those have to reference the nunit assemblies they will be used with when they are installed. Getting it right is tedious at best, requiring multiple visits to the Add Reference Dialog. And from time to time, Visual Studio will decide to use a different assembly from the one you expected.
I finally got fed up with all this and decided to write a NAnt script for one of my addins - CSUnitAddin actually. After it was done, I looked closely and realized that most of it was boilerplate - the same code with a few property changes would build other addins. So I started to factor out the common code into an include file, with the result that my CSUnitAddin.build file now looks like this:
<?xml version=”1.0″?>
<project name=”CSUnitAddin” default=”build” basedir=”.”><!– Include the common build file –>
<include buildfile=”../common.addin.build”/> <!– 1 –>><!– Define non-default names for sample project –>
<property name=”sample.dll” value=”money.dll”/>
<property name=”sample.dir” value=”money”/><!– Define non-default names for fixture project –>
<property name=”fixture.dll” value=”CSUnitTestFixtures.dll”/>
<property name=”fixture.dir” value=”CSUnitTestFixtures”/><!– This addin is for the csunit framework –>
<property name=”target.framework.dll” value=”csunit.dll”/><!– Define alt library with proper version of csunit –>
<!– Must be here since lib.dir is defined in the common file –>
<property name=”csunit.version” value=”2.0.4″/>
<property name=”alt.lib.dir” value=”${lib.dir}/csUnit-${csunit.version}”/></project>
This example actually has to do more than most, since it uses a “foreign” testing framework. I’ll walk through the steps for you:
- First, the script includes the addin.common.build sript, which will do all the work.
- Next, it defines non-standard names for the sample assembly and it’s directory. I could have eliminated this by calling them both “sample” but I wanted a non-generic name here.
- I do the same thing for the “fixture” assembly - an assembly that contains csunit-based tests, which are loaded and run by my unit test assembly. In this case, I might have stuck with the default (CSUnitAddinFixture) and saved a few lines of xml.
- I set the target.framework.dll to csUnit so that my sample and fixture assemblies will be built with a reference to that framework rather than the default nunit framework.
- This particular addin has multiple library subdirectories for different versions of csUnit, so I set the alt.lib.dir property to indicate which one I want to use.
So, let’s say that I want to build and test this addin with NUnit 2.5, using both the .NET 1.1 and 2.0 builds. I can do this with two commands:
nant release net-1.1 nunit-2.5 clean build test
nant release net-2.0 nunit-2.5 clean build test
The script will locate my NUnit 2.5 installation, build the addin and it’s associated assemblies (four in all), install it and run the tests using that same installation. NUnit 2.5 has separate net-1.1 and net-2.0 directories, which the script knows about, so the two builds will be installed separately.
This is how I’m building addins now. I use Visual Studio to do editing and syntax checking, leaving the actual builds to the script. As a result, I no longer need to deal with mismatched references or with the tedium of using the gui to switch between NUnit versions.
The Common.Addin.Build script is open source, licensed under the Academic Free Licence 3.0. You can get it here.
Testers in our agile team (Simon Baker)
In the pre-planning game with the Product Owner, Customer and a few developers, the testers help grease the wheels for the coming iteration's planning game by teasing out, through conversation, preliminary details about the candidate stories to get them to about the right size. Details are noted in pencil on the reverse side of the story cards. The planning game is similar to the pre-planning game except the whole team is present. Typically, the Customer is absent because the conversations can get technical in order to estimate the stories but the Customer can be there if they want. Again, the testers help tease out story details and capture these as acceptance criteria, in pencil, on the reverse of the story cards. The team works together to identify the right acceptance criteria for each story. The planning game is about doing just enough planning to reach consensus on estimates and commit to a delivery goal. Everyone understands that, as collaboration occurs and the story is developed, it may be necessary to add, remove or modify acceptance criteria.
When stories are started in an iteration, developers build them out in vertical slices that satisfy specific acceptance criteria. When a slice is ready, the developers have a conversation with the testers, demonstrate its functionality and walk through the automated acceptance tests. When the testers are happy they're left to run their automated build, which deploys the latest code to their environment. Here they'll conduct their exploratory testing. Exploratory testing functionality as it emerges, slice by slice, helps avoid a tail-end testing crunch in the iteration or, worse, trailer-hitching testing in a separate iteration. Developers might also ask the Product Owner and Customer to preview a slice to get more feedback. When this happens, the testers act as chaperones to keep abreast of emerging details and are part of any decisions made relating to the story.
Testers starve without slices so they pull slices from developers on a regular basis to maintain a flow of stories that ultimately make it to done in time for the showcase.
Defects are rework and an expensive form of waste. When a defect is found in a story and the story is still being developed, the defect is a stop-the-line event. The testers interrupt the developers working on the story and ask them to fix the defect in the next slice. This conversation usually includes the testers showing how to reproduce the defect. If the story is no longer being developed - maybe the defect was discovered after a story was completed - the testers write the defect on a pink card, which is then placed at the top of the board, so it will be the next card to be started.
Testers on our agile team have found their working day to be very different. They're using the same testing skills and they're finding new skills as they collaborate more within the iteration.
Tags: testing, agile, collaboration
Maybe Pair Programming isn’t such a good idea (Steve Freeman)
“Keyboads dirtier than a toilet” (BBC)
It justifies my view that eating lunch at the desk is uncivilised, and that pairing stations should have two keyboards.
Now that everything is USB, maybe we should just carry our own input devices and just plug in when wherever we’re working. Hmmm. Sounds like my dissertation, maybe I should have stuck with it…
Finding Bugs is Easy (Greg Vaughn)
Using Addins with NUnit-Console (Charlie Pool)
A recent bug pointed out that addins are not recognized when running tests under the console runner. This is due to a missing entry in the nunit-console.exe.config file, which you can easily fix yourself. Follow these steps to have your addins recognized when using the console runner:
- Open the nunit-console.exe.config file in any convenient editor - notepad is fine.
- Find the <runtime> element
- Insert the code below within the <runtime> element. You can copy it from nunit.exe.config if you prefer
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="addins"/>
</assemblyBinding>
From this point on, your addins should work equally well in both the Gui and Console runners.
NUnit 2.4.7, 2.5, 3.0: What’s With That? (Charlie Pool)
A few folks are confused by the various release numbers being announced or discussed all at one time, so I thought I’d clarify:
NUnit 2.4.7 is the latest production release of NUnit. It’s the one we recommend most people use for your tests. Some fairly critical performance bugs have been fixed in the last few releases, so you should update even if you’re only one or two digits back. See what you’re missing !
NUnit 3.0 is the planned - but not yet released - next generation NUnit. We call it the NUnit Extended Testing Platform, to distinguish it from the current NUnit Framework. It will provide a superset of the functionality of the current framework and is generally described here. I’ll be posting further info on NUnit 3.0 as it progresses.
NUnit 2.5 is release that wasn’t originally planned. The 2.4 series was supposed to be followed by 3.0. However, a number of people asked for a quicker release that included features provided by other test frameworks, which are currently missing from NUnit. So 2.5 is now in alpha, with extensions to support data-driven tests, easier exception testing and a number of other goodies. It’s also being bundled with pNUnit, an extension that supports distributed parallel tests. See the release notes for details. Watch for the second Alpha release sometime next week.
Hopefully, this will clear things up till we generate some more numbers.
The difference between blame and accountability (Simon Baker)
Deal with the root cause. Have a conversation and hold the person accountable.
To me, the difference between blame and accountability is language and delivery. Here's a couple of examples:
"That code you wrote to do thingamyjig is rubbish. It's causing all sorts of problems."Here you're assigning blame, which can be exaggerated with intonation and gesture.
"You know that code you wrote to do thingamyjig?Here, on the other hand, you've approached the person, offered to help improve the code and created a learning opportunity for him (and probably for you too) that will help address the root cause and prevent it from happening in the future.
I think there might be a better way to do it. Can we sit down and try refactoring it?
I'd like to show you what I'm thinking and get your feedback on it."
Tags: communication, accountability, blame
People do pair-programming (Simon Baker)
- Keyboard hogging
- Drivers over-doing the running commentary
- One-way conversations
- Procrastination through too much discussion
- Copilots disengaging
- Copilots playing on their handheld device
- Copilots not thinking at a system-level thinking
- Holding one another accountable for smelly code
- People not remaining aware of other person's skills and level of experience
Here's some of the posters:
I wanted to emphasise the need for effective communication because, as a team, we're highly collaborative and extremely conversation-driven, so I spent 10 minutes talking about it. Everyone knows that communication happens in many ways - language, gestures, pictures, code, etc - yet people often don't recognise that everyone wants to get along and do their best. When people sometimes respond to something you've said in an unexpected way - maybe they're argumentative or obstinate, or perhaps they look confused - there are usually good reasons. Responding in kind is not the way to go. That's just going to make the conversation spiral negatively. Consider how the other person might have interpreted what you said. Find out what possible reasons might exist for their reaction.
A conversation is simply an exchange of information but they can be hard work. It's important to alternate between informing and listening. If you're saying something, don't assume your message is received. Ask for acknowledgement. Ask the other person to play it back to you. When speaking, delivery is everything. Is your delivery causing people to not listen? Saying it louder probably won't work. Try saying it differently. If you're listening to someone, don't just hear them, actually listen. Maintain eye contact, visibly show interest and focus on what they're saying. Verify your understanding by playing it back to them, in your own words.
People label people. These labels essentially stereotype people and encapsulate how you expect them to behave. Labels are a handy means of characterizing a person but they can create negative perception. "What I don't hear, I make up, and I hold you responsible for it." It's difficult but you need to at least be conscious of the labels you use.
Communication needs to be congruent. Balance your own needs, desires and goals against those of others, taking into account the context or environment in which you're interacting. Every person is different. Every pairing session is different. You have to invest in growing a pairing relationship over time with every person in the team.
The action we took out of the retrospective was to give and get feedback within pairs after each pairing session using a 10-minute reflection on the interaction. Here's how it works:
At the end of each pairing session the pair rip an index card in half and each person writes his name at the top of the half-card. The pair discusses the session and each person makes notes on their half-card about what worked well for them, what didn't, and where the interaction can be improved. They do not critique one another. When complete, they exchange the half-cards providing each person with a reference to the pairing session from the other person's perspective. When the pair comes together again they combine their card-halves and work together to improve their relationship and interaction. At the end of each pairing session, the pair writes new card-halves to drive continuous improvement.
We'll run with this for a while and see what happens.
Tags: pair-programming, promiscuous pairing, communication, retrospective, collective code ownership, collective story ownership
Two kinds of YAGNI (Steve Freeman)
I seem to be blog-stalking Keith again.
In his post on Creation under Constraints he uses a post from Andrew Binstock to write about the benefits of discipline on creativity. After all, is there anything more constrained than the form of a Rock’n'Roll song? Bartok had a thing about using the Golden Ratio to structure his work. Even in my misspent youth playing free jazz, the good musicians had an identifiable voice that implied form and structure.
Getting back to the point (there is one? ed.), the phrase You Ain’t Gonna Need It (YAGNI) often seems to be applied at the micro level by using primitive types: I’ll just use a String for this address, I can figure out whether I need a type later. Except that, later there are Strings all over the code, only some of which should be Addresses and, by the way, it turns out that I’ve assigned some company names (also String) to address fields by mistake.
String is about implementation, it’s not expressive in the domain of the code. And I’d double that claim for anything that involves templated collections, when there are three or more levels of nested angle brackets it’s time to turn back.
An alternative view, is to say: I need an Address, I’ll declare an empty type and add features as I discover the need. I don’t expect to need a getBytes() method on Address, but I might well need to ask it for its post code.
Over time, I’ve become more and more convinced of the value of declaring types for everything. I don’t observe this practice as much as I think I should, probably for the same reason I have too many fillings.
Incidentally, for a fine example of working under constraints, the Abelson and Sussman videos go for hours before they discover a need for mutable values.
We’re famous (kinda) (Steve Freeman)
There’s been quite a buzz in the narrow world that I inhabit about this recent interview with Donald Knuth. For us “TDDers”, the relevant quote is:
[…] the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”
Keith has discussed this point nicely. Personally, in a scarily long time in software (which including tourism at some of the best research labs in the world), I know of a handful of people who can think very hard and then type in a working program of more than 3 lines.
In the meantime, I’m curiously chuffed that the concept of mocking appears to have entered the vocabulary of someone so far away.
As I said, I inhabit a very narrow world.
What I've Been Using Lately (Bret Pettichord)
The Art of Agile Development: Ubiquitous Language (James Shore)
| 30 Apr 2008 | James Shore/Agile-Book |
in 99 words
Programmers should speak the language of domain experts to avoid miscommunication, delays, and errors. To avoid mental translation between domain language and code, design your software to use the language of the domain. Reflect in code how users of the software think and speak about their work. One powerful approach is to create a domain model.
The ubiquitous language is a living language. Domain experts influence design and code and the issues discovered while coding influence domain experts. When you discover discrepancies, it's an opportunity for conversation and joint discovery. Then update your design to reflect the results.
as haiku
Fireflies light the night--
Signaling for a mate, or
perhaps, a dinner
Inside This Section
- The Domain Expertise Conundrum
- Two Languages
- How to Speak the Same Language
- Ubiquitous Language in Code
- Refining the Ubiquitous Language
- Questions
- Should we avoid the use of technical terms altogether? Our business domain doesn't mention anything about GUI widgets or a database.
- Results
- Contraindications
- Alternatives
- Further Reading
History
In the first edition of Extreme Programming Explained: Embrace Change, Kent Beck introduced the "Metaphor" practice, also called "System Metaphor."
Each XP software project is guided by a single overarching metaphor. Sometimes the metaphor is "naive," like a contract management system that is spoken of in terms of contracts and customers and endorsements. Sometimes the metaphor needs a little explanation, like saying the computer should appear as a desktop, or that pension calculation is like a spreadsheet. These are all metaphors, though, because we don't literally mean "the system is a spreadsheet." The metaphor just helps everyone on the project understand the basic elements and their relationships.
The words used to identify technical entities should be consistently taken from the chosen metaphor. As development proceeds and the metaphor matures, the whole team will find new inspiration from examining the metaphor.
The metaphor in XP replaces much of what other people call "architecture." The problem with calling the 10,000-meter view of the system an architecture is that architectures don't necessarily push the system into any sense of cohesion. An architecture is the big boxes and connections.
You could say, "Of course architecture done badly is bad." We need to emphasize the goal of architecture, which is to give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks. By asking for a metaphor we are likely to get an architecture that is easy to communicate and elaborate.
Kent Beck, Extreme Programming Explained: Embrace Change
This didn't work out so well. Detractors of XP latched on to System Metaphor as an example of XP's irresponsibility: of course architecture is important! How could it not be? How could this silly idea of "metaphor" replace architecture?
On the flip side, people who liked and used XP struggled to understand the idea of System Metaphor and its place in XP. Early XP conferences had whole workshops devoted to coming up with a metaphor for your system. Its meaning and purpose was debated on Ward's Wiki, source of the best and most complete early information on XP. On my first XP project, the one where tried everything religiously, we dabbled with system metaphor, too, giving our classes names like "forklift" and "warehouse." (Our system was a data warehouse, you see. Except that it wasn't.)
Most people just ignored System Metaphor. Kent Beck stuck with it for a while, but eventually dropped it as well. When the second edition of XP Explained was published, System Metaphor was gone, with nothing to replace it.
Meanwhile, Joshua Kerievsky had created Industrial XP (IXP). IXP never really caught on, possibly because the name was so similar to the name of Joshua's company, Industrial Logic. It was a good method nonetheless. I had the opportunity to coach a team in its use as part of an long-term coaching effort in Toronto.
Joshua was a reviewer for Eric Evan's excellent book, Domain-Driven Design. It's probably no coincidence that Domain-Driven Design is an explicit practice in IXP. The IXP web site quotes Evan's book to describe the practice:
The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process. Domain-Driven Design fills this need.
Eric Evans, Domain-Driven Design
I think domain models are an excellent tool and Eric's book is wonderful. Domain models aren't appropriate in all situations, though, which is why we didn't include domain-driven design as a practice in our book. Instead, we used another pattern from Eric's book: Ubiquitous Language.
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of the design.
The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing.
...Therefore:
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Eric Evans, Domain-Driven Design
As I look at the IXP site now, I don't see any reference to Ubiquitous Language. But I seem to remember that it was a major part of that project in Toronto. That's probably why it was on my mind when I mentioned it to Shane as a possible practice for our book.
Programmers program in the language of technology: classes, methods, algorithms, and databases. Domain experts talk in the language of their domain: financial models, chip fabrication plants, and the like.
You could try to translate between the two languages, but it will add delays and errors. You'd produce some software eventually, but you'd probably introduce some bugs along the way. Instead, pick just one language for the whole team to use--a ubiquitous language.
James Shore and Shane Warden, The Art of Agile Development
So here we are, full circle. The core idea of System Metaphor was to "give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks." (Beck00) And the core idea of Ubiquitous Language is to "reflect in code how users think and speak about their work." (Shore07)
Right back where we started, except without that funky metaphor stuff.
Reintegrating Watir and FireWatir (Bret Pettichord)
Rsync Your Referrer log (Greg Vaughn)
#! /bin/sh
rsync -Cavz -e ssh --delete /Users/gvaughn/Sites/gigavolt.net/blosxom/ \
userid@webhost.com:/WebSite/gigavolt/blosxom/
rsync -urptgovLz -e ssh --copy-unsafe-links \
userid@webhost.com:/WebSite/gigavolt/blosxom/ \
/Users/gvaughn/Sites/gigavolt.net/blosxom/ And my book goes farther east! (Jimmy Nilsson)
So cool!
Not only has my latest book, "Applying Domain-Driven Design and Patterns" been translated into Russian
(more information here), but now I've been informed that the Japanese translation has been published as well. The Japanese version
looks like this:
Should We Adopt Scrum or XP? (James Shore)
| 26 Apr 2008 | James Shore/Blog |
A reader recently asked:
I have learned a bit about Scrum and Crystal and found that things are looser and they do not prescribe practices as XP seems to and that they want you to work toward finding the practices that work for your team. An example is Mike Cohn saying that he does not like to prescribe practices, like TDD which he believes in, but wants the team to discover for themselves their need of it as they do root-cause analysis and retrospectives. Does this go against y'alls advice on trying to do all the practices and later adjusting things to meet your needs as a project? Or is it something different?
[For example, see] Mike Cohn's thoughts about Scrum and XP. In particular starting with Scrum and creating your own XP.
My response:
I agree with Mike Cohn's description of the differences between XP and Scrum. I would emphasize that Scrum and XP are very similar, with the exception that XP includes more "how to" practices. There's also a bit of an focus difference; I feel like Scrum's focus is "let's create a self-organizing team" and XP's focus is "let's create excellent software." In other words, when I talk to Scrum people, they tend to talk more about self-organization and enabling the team; when I talk to XP people, they tend to talk more about software and delivering value. But despite that difference in attitude, the actual practices are very similar.
Mike's closing statement, that Scrum brings big benefits by itself, matches my experience. Scrum is also easier and less threatening than XP, so I see a lot more people starting out with Scrum. On the downside, the teams that start with Scrum tend to struggle more than the teams that start with XP. The XP teams experience more pain starting out, but then get to a high performance state within the first year. The Scrum teams I know have a much longer ramp-up time, generally having code quality problems for several years. Actually, I have yet to meet one that wasn't having code quality problems. None have gotten to the same high performance result that good XP teams do.
Granted, these statements are based on my experience, and my experience is formed by the people I meet at conferences and the companies who hire me. High performance teams generally don't hire me, so it could be that I'm not meeting the high performance Scrum teams.
Nonetheless, my experience is that Scrum teams have an initial success and then struggle. XP teams struggle to get started, but once they figure it out they have more success. Sometimes they don't figure it out, fail, and give up. With Scrum, teams seem less likely to realize that haven't figured it out; I've met teams who said they were using Scrum but weren't doing anything of the sort; they were just using the terminology. That happens with XP, too, but to a lesser extent, and usually of the form "we're doing XP but not..."
To boil it down to simple statements (perhaps too simple):
Scrum: easy to adopt, very hard to master, fails quietly. You're more likely to successfully adopt Scrum, but the benefits won't extend to your codebase and you'll struggle with legacy code for many years. If you're missing pieces, you may not realize it.
XP: hard to adopt, easier to master, fails noisily. You're less likely to successfully adopt XP, but you'll be well positioned for long-term success and mastery. If you're missing pieces, you'll probably be able to tell.
I have one complaint about Mike's essay. XP doesn't prescribe engineering practices, as Mike says; it includes them. For teams new to agile development, I do recommend that you use all of the practices from the start. However, a team that knows what it's doing will change its practice of XP over time. No two experienced XP teams practice XP in the exact same way, and there's no requirement that you do exactly what the books say. For example, one long-running XP team I know has evolved away from using iterations entirely, but I'd still think of them as practicing XP.
However, in order to know what to change, you have to know how the techniques work in practice. That's why I recommend starting out with all of the practices. Otherwise, it's like deciding to be an avant-guarde violinist without first mastering the violin.
Should you start with Scrum or XP? I recommend starting with XP, but Mike's right--you won't succeed if you force the practices down people's throats. The team has to agree to try them. If they're not ready to do that, you might be better off starting with Scrum. Then you can use that success, along with some of the code problems you'll encounter, to guide them to XP.
Finally, if you have the opportunity to get a coach to help you adopt your method, I recommend that you do. A good coach will help the transition go a lot more smoothly.
Save Your Job: Dispelling Illusions of Fear Disguised as Ethics (Sammy Larbi)
Software Development as profession? Not Yet, Probably Never (Mark Levison)
In discussing Scott Bain's book: Emergent Design: The Evolutionary Nature of Professional Software Development Martin Heller asks Is "professional software developer" an oxymoron?
In the book (which I've not read yet), Scott makes the case for the use design patterns, test driven development, coding style and readability. This sounds like the book we all wish our colleagues would read (not ourselves of course - we're already perfect).
Martin then hones in on Scott's suggestion:
that software development is by nature a professional activity, and should be conducted as a professional activity. He also says that we're not yet conducting it as a professional activity.
He finishes by asking the question 'Is the phrase "professional software developer" an oxymoron?' My answer is no, but I think the question misses Scott's point. Scott is asking to consider what it would take to become a profession as a way to force us to start wrestling with difficult questions. I agree that we need to start asking difficult questions especially with the mounting numbers of costly failures in large out of control projects (both public and private sector).
But I would argue strongly against seriously considering becoming a profession. My concerns are two fold: would standardisation limit the testing and adoption of new ideas and look what happens in the name of a profession in some other fields.
- Consider if we had become a profession 10-15 years ago. Waterfall development and lengthy reviews of every output would be mandatory. How Agile, Lean and the related engineering practices have grown up in that environment? If we standardised today how would we improve on what we have now.
- Also be careful of the professional bodies you seek to mimic. The American Psychiatric Association has in recent years defined a number of diseases largely based on the lobbying of drug companies that wish to cure them. I shudder to think what the right people with money would do to the Software Professional Association.
So I agree with Scott this industry needs a shake up and we need to seriously consider how to get better. But I think that becoming a profession is the wrong path to take.
I look forward to hearing other opinions.
If you enjoyed this post, subscribe now to get free updates.
Kate Oneal: Diet Cola With Carl (XProgramming.com)
Where's the money? (Simon Baker)
| Women's | Men's | |
|---|---|---|
| Weekly demand | 120 | 120 |
| Price | 105 | 100 |
| Raw material cost | 45 | 50 |
| Cutting time | 2 | 10 |
| Sewing time | 15 | 10 |
| Total process time | 17 | 20 |
Each machine has an operating capacity of 2400 minutes per week and the company's weekly operating expenses are £10,500.
| Machine | Minutes necessary for women's shirt | Minutes necessary for men's shirt | Total minutes necessary | Necessary minutes / available minutes |
|---|---|---|---|---|
| Cutting | 240 | 1200 | 1440 | 60% |
| Sewing | 1800 | 1200 | 3000 | 125% |
Clearly, there is not enough capacity at the sewing machine to satisfy the market demand for both types of shirt. The company does (maybe) the obvious thing and focuses on the most profitable product. It satisfies all the demand for the most profitable type of shirt first and then uses the remaining time at the sewing machine to make the other type of shirt. The women's shirt is more profitable. It sells for more, fabric costs are less and it is quicker to make. The company can make 120 women's shirts using 1800 minutes at the sewing machine. The remaining 600 minutes at the sewing machine allows us to make 60 men's shirts.
| Revenue from women's shirts (£105 x 120) | £12,600 |
| Revenue from men's shirts (£100 x 60) | £600 |
| Total revenue | £18,600 |
| Raw material cost for women's shirts (£45 x 120) | £5,400 |
| Raw material cost for men's shirts (£50 x 60) | £3,000 |
| Total raw material cost | £8,400 |
| Gross margin | £10,200 |
| Operating expense | -£10,500 |
| Net profit | -£300 |
By focusing on the most profitable shirt the company ends up making a £300 net loss every week.
Say the company did something else. Let's say it decides to make 120 men's shirts and use the remaining time at the sewing machine to make women's shirts. 120 men's shirts use 1200 minutes at the sewing machine. The remaining 1200 minutes at the sewing machine allows us to make 80 women's shirts.
| Revenue from men's shirts (£100 x 120) | £12,000 |
| Revenue from women's shirts (£105 x 80) | £8,400 |
| Total revenue | £20,400 |
| Raw material cost for men's shirts (£50 x 120) | £6,000 |
| Raw material cost for women's shirts (£45 x 80) | £3,600 |
| Total raw material cost | £9,600 |
| Gross margin | £10,800 |
| Operating expense | -£10,500 |
| Net profit | £300 |
By increasing the production of the least profitable product while decreasing the production of the most profitable product the company ends up making a £300 net profit every week. Conventional cost accounting wants to minimise the cost of making a product based on the assumption that the lower the cost of a product, the greater the company's profit. One element in the cost of making a product is the time the product uses company resources. Therefore one way to reduce the cost is to reduce the time at a machine.
For a £100 investment we can reduce the cutting time of a men's shirt from 10 to 8 minutes. That's a 10% reduction in the total process time for a men's shirt, down 2 minutes from 20 to 18 minutes. This is a good investment from a cost accounting perspective. Trouble is it won't increase the overall net profit. The company will still have the same bottleneck on the sewing machine so it can't produce any more shirts than it could originally. The weekly net loss is worse, -£302 (net loss plus -£2 which is approximately the investment of £100 spread over 52 weeks).
For a £1000 investment the company can decrease the sewing time of a women's shirt by 1 minute and increase its cutting time by 3 minutes. This increases the total process time for a women's shirt by 2 minutes. Cost accounting would probably reject this because it increases the product cost. However, by reducing the sewing time required by women's shirts the company has effectively created more capacity at the sewing machine, which allows it to make more women's shirts and satisfy more of the market's demand.
| Revenue from men's shirts (£100 x 120) | £12,000 |
| Revenue from women's shirts (£105 x 85) | £8,925 |
| Total revenue | £20,925 |
| Raw material cost for men's shirts (£50 x 120) | £6,000 |
| Raw material cost for women's shirts (£45 x 85) | £3,825 |
| Total raw material cost | £9,825 |
| Gross margin | £11,100 |
| Operating expense | -£10,500 |
| Investment | -£20 |
| Net profit | £580 |
By increasing the process time of a product, and therefore increasing its cost, the weekly profit has almost doubled.
A company's capacity to produce and sell product is a system or chain of interdependent activities. Trying to maximise profits by cutting costs and investment will eventually damage a company's capacity to make sales. The goal of every company is to make money, not to save costs. Capacity should be protected. A company should do everything possible to uncover excess capacity (by eliminating waste and re-evaluating how things are working) and find new ways to use its existing system and the costs built into it to generate more profit without significantly increasing investment. Then it should look to reduce investment (because that increases Return On Investment) but only by producing less inventory, i.e. product that has not been sold. Cutting costs is the easy option - it should be the last option a company considers.
Tags: value, throughput accounting
ANSI Art Extravaganza (Sammy Larbi)
The Art of Agile Development: Real Customer Involvement (James Shore)
| 23 Apr 2008 | James Shore/Agile-Book |
in 99 words
To widen your perspective, involve real customers. The best approach depends on your market.
Personal development: you are the real customer. Congratulations. Go forth and write algorithms.
In-house custom development: turn your real customers into on-site customers.
Outsourced custom development: get real customers to be on-site customers. If you can't, stay in touch and meet face-to-face frequently.
Vertical-market and horizontal-market software: beware of giving one customer too much control. Appoint a product manager to understand customer needs. Create opportunities to solicit feedback. Examples: customer review board, beta releases, and user experience testing.
as haiku
roses, cucumbers--
I chose beauty, but Sensei
desires to eat
Download this poster!
Inside This Section
- Real Customer Involvement
- Personal Development
- In-House Custom Development
- Outsourced Custom Development
- Vertical-Market Software
- Horizontal-Market Software
- Questions
- Who should we use as on-site customers when we can't include real customers on the team?
- We're creating a web site for our marketing department. What kind of development is that?
- Results
- Contraindications
- Alternatives
Commentary
It's all about communication.
I like to say that successful software requires three components: organizational success, technical success, and personal success. Organizational success because we need to turn a profit, or realize some other sort of value. Technical success because we don't want to throw away the software and rewrite it every few years.
What about personal success?
When Shane and I were first writing the book, I thought of personal success from the perspective of the development team. "Without personal success, you'll have trouble motivating yourself and employees," we wrote. And that's true. In thinking about it further, though, I've come to realize that personal success is much more important than that.
Much as we might like to believe otherwise, we humans are fairly irrational creatures. We tend to make decisions for emotional reasons rather than logical reasons. That's where personal success comes in. You might be building the best thing in the world, but if your project doesn't make the person thinking about it feel good--if it doesn't contribute to her personal success in some way--she's not gonna love it. And if she doesn't love it, she's not likely to push it. And if nobody else important pushes it either... goodbye, project. The end.
It gets worse. Sometimes the need for personal success leads to sabotage. True North pgs tells the following (true) story in their Mastering Projects workshop:
Jerry was furious [about his project being cancelled]. After investing so much time and energy in the project, he was intellectually convinced of its importance and he was emotionally committed to it. Could the company be this stupid, he wondered? Do I really want to work for a company that is this stupid?
At 4:45 p.m. Jerry resigned and went home. His boss called him two or three times the next day, but Jerry refused to take the calls. It took him a week to get over his rage. It took another six weeks to get a new job.
Shortly after Jerry started his new job, he received a call from an old friend still working for his previous employer. Jerry's friend related a story that was circulating among some of the people there. The story went like this: An executive in the Sales Department learned of Jerry's project about three weeks before the project was terminated. According to the story, he instantly disliked the idea, basically because selling the equipment would require a knowledge of hospitals and medical-purchasing practices that his sales force did not have. So, according to the story, he got one of his people to fabricate some very pessimistic numbers about market potential. He sent these numbers to a marketing executive, who was also a good friend, along with a note asking, "Why are we wasting research on this project?"
True North pgs., "Mastering Projects Workshop."
Adapted from John Kotter's Power and Influence, 1987.
Personal success. It's so damned personal.
So. Keep personal success in mind. Not only do you need the support of important stakeholders, you also need to avoid sabotage. How? Talk to people. Find out what their interests are. Watch for little reactions when you describe various features. Ask if your needs make their lives difficult. Offer to help ease their pain. Give them a chance to be a part of your success.
It's all about communication.
Rasta supports data-driven testing (Bret Pettichord)
FOAF Images (Ian Davis)
Back in 2002 I submitted four cute faces as my entry in the informal FOAF icon competition. Now those images are pretty ubuquitous but somewhere in the intervening years and server moves the page I maintained linking to them disappeared. With a nudge from danbri I put together a new page to serve as their home: http://iandavis.com/2006/foaf-icons/
Kate Speaks: Background and Prologue (XProgramming.com)
Upgraded to Wordpress 2.5 (Ian Davis)
I finally made the upgrade. Some things might be a bit wonky around here, especially as I converted all my categories to tags. Expect some broken links and feel free to comment here if you spot anything missing. On the plus side, I added a new Sitemap-style page
Cloud Security (Ian Davis)
Just came across a new blog called Cloud Security by Craig Balding that looks to have a lot of potential. Cloud computing is definately the trend du jour and we need more discussion and information around the security of cloud services.
Wonder if it’s this Craig Balding?
One for the subscription list…
Yo Sam, RTFM! (Sammy Larbi)
The Terrible And Tragic Tale Of Brian The Snail (Ian Davis)
While clearing out some old papers and files I’ve carried around with me since I left University, I came across this poem that my friend Dominic Taylor wrote for me. It’s based on a true story, an event that occurred to me in early 1991. I thought the poem had been lost forever, so I was ecstatic when I found it.
The Terrible And Tragic Tale Of Brian The Snail
(after William McGonagall)
OooooooOOOOoooOOooooooooooH!
‘Twas in the year of nineteen hundred and ninety one
When, alack, a poor snail was undone.
Brian, for such was the name of this monoped,
Being in danger for shelter had fled.
Not being possessed of much great speed
This was for Brian no easy deed.
And so, not surprisingly, try as he might
He would have been unsuccessful in his flight,
Had he not with sharp eyes aspied
A place where with impunity he might hide.
“And where was this sanctuary?” I hear you beg;
It was in the turn up of Ian’s trouser leg.
The cause of his trouble may now be heard
Brian was menaced by a terrifying bird
Who, feeling peckish, was desiring of lunch.
(He always ate snails because they made a nice crunch).
To return to tale, and I do think we should,
Our hero the snail was not quite out of the woods.
For though Ian lumbers at a rather slow pace
For Brian to catch him it was still a hard race.
So the plucky mollusc sped across the ground
Always spurred on by the terrible sound
Of the bird screeching and screaming and flapping its wings
And threatening poor Brian with terrible things.
The snail was fast but the bird was still faster,
And Brian thought the day would end in disaster.
Then just as he was praying for Ian to wait
He was miraculously saved by interceding fate;
As luck would have it, on a stone Ian tripped,
And into his turn up Brian Snail slipped.
However, when he thought he was safe; in sight was his doom
As Ian mounted the stairs and entered his room;
For exhausted by his exertions down the lad sat
And Brian was crushed with a horrible “splat!”
The moral of this story should be easy to guess:
If you jump in Ian’s trousers you’ll end up a mess.
Dominic Taylor, Spring 1991
Create business value by focusing on end-users (Simon Baker)
At the end of the day, the goal
of every company is to make money. So, ultimately, a business values things that make it money. We should always do our utmost to deliver value to our business by giving it the things that will help it make money from its customers. But focusing directly on business value is not good idea. Making money is most definitely the goal but focus must be on the source of revenue - the customers or end-users. If a business focuses on the money it eventually does wrong by its customers and they go away and it makes less money.Imagine a business that makes reasonable money from adverts displayed in a heading or sidebar on its Web site. As user numbers increase, the business sees the potential to make more money from advertising and increases the amount of advertising space on its pages. It also introduces pop-up adverts, all without considering the effect on the users' experience. It turns out that customers don't like the more intrusive advertising. It gets between them and the reason they visit the site so they gradually stop visiting. The business is left with plenty of adverts but fewer customers to click on them.
Pursuit of revenue to the detriment of customers is a pretty good way to not make money.
Drucker said every company should ask itself 3 questions:
- Who are our customers?
- What are their needs?
- What do they consider value?
Tags: value, customer, end-user
Save Your Job: Commit, Execute, and Let It Be Known (Sammy Larbi)
I Want Subtext (James Shore)
| 17 Apr 2008 | James Shore/Blog |
I haven't been this excited about a programming language since I tried to invent my own.
Programming in Subtext
Subtext is a programming language invented by Jonathan Edwards. It's based on schematic tables (see figure) which display logic and computation in two dimensions. In contrast, textual languages show just one dimension (a stream of characters), and it's usually computation. Introducing conditionals requires you to puzzle out control flow.
Subtext makes logic and computation obvious by placing them on two axes in a table. To understand how this works, I recommend watching Jonathan's video demonstrating Subtext. (If you saw the video for the original version of Subtext, watch the new one--it's come a long way. I didn't even recognize it.)
Subtext nails a bunch of things that I want. To explain, I'll need to digress for a moment.
Example-Driven Development
My background is in commercial software development in a wide variety of industries. I'm passionate about seeing software lead to real-world successes, which involves organizational success (return on investment, to oversimplify), technical success (maintainable code), and personal success for the systems' community. I've dedicated my career to improving my understanding of those three components of software development. I still have a long way to go.
Along this journey, I discovered Agile methods and I've became fairly proficient with them. Two Agile techniques that I've found to be particularly powerful are Test-Driven-Development (using a tool like JUnit) and Example-Driven Requirements (using a tool like Fit).
A Fit document
JUnit and its brethren are great. TDD works well. Example-driven requirements also works well, but I've become increasingly dissatisfied with Fit. Fit, in case you haven't heard of it, is a tool created by Ward Cunningham and maintained, in a laissez-faire sort of way, by me. It allows you to provide domain-level examples in HTML tables, then automatically test those tables via fixtures that execute the table against your production code.
The great thing about Fit is that it enables example-driven requirements. This is incredibly powerful and useful, and Fit is the only tool I know of that focuses on this. (Most clones of Fit get it wrong, focusing on test automation rather than customer collaboration.)
The problem with Fit is that it's a maintenance burden. You have to write your examples in HTML and none of the existing tools (not even MS Word) make editing and revising HTML tables easy. You have to create fixtures. When done well, fixtures are small and simple, but they're easy to get wrong. You have to deal with Fit's primitive and difficult-to-use tool support. (Okay, I could fix this one, and should.) And, to top it off, almost everybody misunderstands and misuses Fit.
Okay, back to Subtext and Jonathan Edwards. TDD and example-driven requirements (EDR) can both be considered cases of example-driven development. In other words, your development efforts are focused around creating examples and making them work. The examples form sort of an incomplete specification of your work that are fleshed out along with your program. TDD operates at the level of programmer intent and EDR operates at the level of customer intent.
Well, Jonathan shares a passion for examples in programming. So it's no surprise that Subtext looks like it will support the Agile conception of example-driven development quite well. The best thing about it is that it looks like it will support TDD, example-driven requirements, and software development within a single paradigm. Brilliant.
Critique
In addition to its support for example-driven development, I like Subtext's focus on making programmers' intent more obvious. The schematic tables are a great way to show what happens computation is mixed with complex conditionals. I particularly liked Subtext's ability to automatically discover gaps and overlaps in conditions. A minor nit: I think Jonathan could decrease the verbosity of his language by allowing more complex statements on each line, perhaps allowing a click to change the view between the simple, linked form shown in the video and more complex compound statements. For example, the Fibonacci example could show the entire >= 2 case in one statement: fib(in - 1) + fib(in - 2). I think I'd actually find that more readable than the current display.
A little light reading
Given that Subtext is a work in progress, I liked almost everything I saw in Jonathan's video. The one thing I disliked was towards the end, as he was talking about polymorphism. I got a sense of disdain towards object-oriented programming. That's not uncommon in the academic world--OOP is anything but well-defined from a formal perspective.
But although OOP is messy, it has an important characteristic that Jonathan also values: it makes programming languages more usable. Objects are an important way of organizing large programs so that the programmer can ignore irrelevant details. Although polymorphism makes control flow more complex, as Jonathan observes, it also enables design techniques that make programs easier to understand.
In a small program, an experienced programmer relies on well-named functions/methods with carefully-constructed semantics. When that's the case, she may use the context of the program to infer the behavior of those functions. For example, if you saw that a mathematical calculation called an "exponent" function, you could guess that it calculated the exponent of a number and move on, not bothering to look at the body of the function unless it was directly related to your work.
Classes and methods perform a similar service in OOP. In a large program, an experienced programmer also relies on well-named classes with carefully-constructed responsibilities. The noun-verb combination of classes and methods allows her to infer the behavior of those classes. For example, if you saw a call to monster.attack(character), you could guess that it calculated attack and damage probability and adjusted character's hit points accordingly.
Subtext's damage calculation gets complicated
Subtext could face challenges dealing with larger, more complicated systems. You can see in the figure how even minor complications in the damage calculation start to make the table unwieldy. Subtext provides a focusing mechanism to hide unnecessary details, but I'm skeptical of how useful the current incarnation is for this purpose. I think it will work well for simple algorithms, but not for the enormously complex, interrelated computations that large systems deal with.
Those enormously complex, interrelated computations are exactly what object-oriented programming languages are good at managing. (With good design, at least, which is by no means a given.)
I'd like to see Subtext give objects a more prominent role in the language. It's hard to tell from the video exactly what's going on, but it looks like the programmers' use of objects is largely limited to defining types and subtypes. I'd like to see more. Specifically, I'd like to see support for named methods attached to objects. They could be expanded and edited in-place, or they could be edited in the context of the object.
Simplifying damage calculation with polymorphic methods
For example, a lot of the complexity of the damage calculation comes from the polymorphic 'power' constants. Magic attacks have a power of 5, melee attacks have a power of 4, and ranged attacks have a power of 3 (not shown in the figure). If Subtext showed that polymorphism as a reference to a method, then the diagram would be simpler. The effect of defense could be similarly collapsed into a 'damage' method.
To continue the example, if the programmer wished, he could open up the 'Attack' class and see 'power' and 'damage' defined there. Perhaps subclasses and/or methods could be shown as columns. That would allow him to contemplate the relationships between the classes and their methods--a common need--and make changes to them together.
This is actually a fairly minor tweak to an impressive system, and it's quite possible that Jonathan has already thought of or even included these improvements. If he hasn't, I hope he'll consider them. Either way, Subtext is impressive. I want it.
(Thanks to Keith Braithwaite for the link.)
links for 2008-04-17 (Ian Davis)
-
“If anything, Amazon demonstrates how a cutting-edge Internet company - of all things - can succeed slowly. The trick is taking a million tiny steps - and quickly learning from your missteps.”
Quotables: Round 5 (Sammy Larbi)
links for 2008-04-16 (Ian Davis)
-
Interview with David Owen on his new book