Rob Lally : Robert Lally

Ending the Era of Patronizing Language Design

I linked, indirectly, to this article the other day and, after reading it again, I agree completely. Well, I agree completely with the notion that we should stop accepting “we didn’t put that feature into the language because you’re too stupid to use it” from language designers.

You really should read the comments accompanying the article, some are wise, many are interesting, unsurprisingly many seem to be commenting on a totally different article.

Now, what this doesn’t mean is that every language should have every feature, it just means that presumed incompetence isn’t an acceptable reason for not having it. Languages need to be designed with taste, discrimination and a desire to facilitate developer productivity.

For too long we have been told by programming language designers that we should eat our steak with a spoon because knives are too dangerous.

What sort of features am I thinking of here? Well, Java is a major culprit of the “you’re too stupid” mindset.

Automatic memory management : This isn’t the sort of feature I’m talking about. This is an enabling feature, something added to the language to help developers. Does it have drawbacks? Sure it does, there are times when direct-to-the-metal can be useful. But a decision was made here to facilitate in one area and compromise in another.

Operator overloading : Can it be used for evil? Sure. So can talcum-powder.. that doesn’t mean we should ban it and force our babies to suffer from trench-nappy-region. There are many cases where operator overloading makes sense and its absence in Java is painful. Exhibit 1 ‘BigDecimal’.

Immutable Strings : Another case of “not what I’m talking about”. Mutable Strings can be useful and powerful, but not having them brings advantages too. This was a conscious decision.

No meta-model : Without a meta model programmers dive into byte code manipulation and magical “doesn’t work like anything else in the language” constructs like DynamicProxy. Can meta-programming be hard and weird? Sure, so is physics. Shall we ban that? It isn’t the same, I hear you cry. You’re damn right it isn’t. Those guys created the atom bomb, and we still let/encourage/train/pay people do it. Heck we teach physics to CHILDREN. There are times in this world, when nuclear fission is just plain useful.

The list goes on.

Sharp vs. Blunt Instruments: “If you want your team to produce great work and take responsibility for their decisions, give them powerful tools.”

(Via Glenn Vanderburg: Blog.)

Hallelujah brother Glen. Everyone say, “praise the power”. C’mon now, say it with me, “praise the power”.

In part 4 of the Scala & Vaadin series I threw in the line “I believe that comments are, for the most part, an abomination” without really explaining it.

There are a couple of comments on that post that I think explain my position - and other people’s reaction - in more detail.

I was out shopping with my wife this morning. We popped into a craft store to allow her to pick up a few things for a project she’s undertaking.

I noticed this :

Which made me chortle a little. The fact that Kanban - Quality As Standard had made it into the realms of hand-crafted gift cards was surprising. Then my jaw dropped at the next card in the rack:

Wow! Waterfall and Kanban, right next to each other competing. Then I noticed this:

It turns out that nobody is buying Waterfall in the craft world. Nobody is buying it, no matter how it is packaged.

I finished off Almost Perfect this morning and I must admit I was a little disappointed by the ending. All the way through the book I’d interpreted Peterson’s actions one way, and then, in the last fifty pages he started to spout his personal philosophy and I realised that I had been interpreting things in a more charitable way than I now feel he deserved.

One of the things that irked me the most was the section where he described how the employees had been asked to work long hours, six days a week for over a year and they’d done it because they were trying to help the company. Then he follows on with complaints about people being unprofessional and visiting the doctors or the dentists during the day. He complains extensively about anyone doing anything not directly work related during business hours - down to being angry at people for showing new baby pictures to colleagues - and then spends long paragraphs describing how productive he was during his afternoon tennis games, or how much he accomplished just by sitting on the beach relaxing and thinking.

“Hi, my name’s Pete. I’m inconsistent and unreasonable.”

I think he must have taken criticism about some of this in the past because the on-line version has a number of the later pages missing. The second-hand copy I got from Amazon was the complete text and the extra light it shone was, as is the nature of light, illuminating.

I’d still recommend the book to anyone who wants to read it. One particular section near the end of the book contained a valuable lesson.

Peterson had described their problems shipping enough copies of a new version of WordPerfect. A few years later, their next major release was due to ship, in the months leading up to their IPO. The launch went off without a hitch and first month sales were at a record level. Then they died off. The next month wasn’t much better. This unexpected, and un-predicted, drop off in sales hit their IPO hard.

During analysis of the slump, they discovered that because their distributors hadn’t been able to get enough product to supply demand after the last major release, they’d over-ordered for the release of the new product. Since they’d over-ordered, they were carrying extra stock and they didn’t need to re-order. This created a month one with unrepeatable sales, making all subsequent months look bad, and months two and three were bad by any standards.

Apart from all the usual lessons about judging sales based on fulfilment of only part of the supply chain rather than completed end-to-end transactions we’re left with a crystal clear example of human behaviour.

People will guess your future performance based on your past performance. It doesn’t matter what you say or do, a man, or a company, is judged by their actions.

Next Friday, the 29th May, Clarke Ching and I are teaching a one day workshop in Edinburgh entitled ‘An Introduction to Agile, Lean and Kanban’.

We’re charging a small fee (£30) to those who’re in full time employment: really, just enough to recoup the costs of renting the room. Entry is free to those who’re currently an ‘under-utilised resource’ (HR speak for unemployed).

If anyone is interested, please contact me at rob@ and I can provide you with details.

I’ve been mulling over my dissatisfaction with BDD, and I’m finally in a position to write down my thoughts.

In short, BDD doesn’t actually seem to be a coherent thing. There are many different perspectives on it, and many different tools with slightly different focusses. The only consistent thing is that the word ’should’ is required to be used anywhere that you would traditionally have used ‘assert’.

To be clear, my argument isn’t with the tools that have been developed: I’m not sure I have a need for ScalaTest or easyb or RSpec or Cucumber, but I think they’re interesting and I hope that future development will lead to something I find compelling. My problem is with the definition of BDD itself.

BDD started off being touted as a replacement for TDD. TDD was too hard, people confused TDD with a testing methodology, people didn’t understand TDD was about design, tests were too hard to read: so the BDD inventors and proponents suggested. Some of this may have been true, there are many people who fail to grasp that TDD was primarily, but not exclusively, about design. Dan North, Dave Astels and others decided that the way to reduce confusion was to change the name; which always reminded me of the way Borland decided to improve sales by changing their name to Inprise.

So here we have it, BDD is a replacement for TDD, now it uses specs and the word ’should’ rather than tests and the word ‘assert’. I thought it was a bad idea at the time because you don’t make things easier for people to understand by having more than one way to say things.

	assertEquals(oneWayToDoThings(), "good");
	many_ways_to_do_something shouldBe 'bad'

I have no doubt that the creators of BDD and RSpec had good intentions. I have no desire to challenge their integrity or their creativity.

As time has gone on, BDD has morphed into a creature that is neither fish nor fowl. BDD specs have morphed, in many cases, to be ‘executable requirements specifications’ which is a laudable goal, but leaves a number of holes.

If a spec is an executable requirement then it is written in customer language. If it is written in customer language then it is of no use as a tool for driving design of classes, methods, objects and functions. So, if this is the home of BDD then it isn’t a replacement for TDD it is something that lives alongside TDD. Mention this to a BDD proponent, though, and you get an argument. You can write specs that cover the same ground as unit tests. Yes you can, but what are the advantages of doing so? You’ll have wordy, obfuscated tests carrying the baggage added to make BDD more palatable for customers and, you still miss out on many of the benefits of TDD.

TDD, as a design methodology, forces you to write code that is used by two different clients: the tests and the final application. This is one of the ways that it helps promote flexibility. It gives you an early look at ‘how exactly am I going to use this class/object’. DBB frameworks don’t look or work like the code that will be calling the final code, so there really is no benefit here. Take easyb as an example, it doesn’t even use the same language as the code you’re writing (assuming the common use case of using easyb as a BDD framework for Java development).

TDD highlights pain points when writing tests, if it is hard to write a test for, your code probably needs a little work. BDD frameworks such as Cucumber, can quite happily support specs written in terms of ‘the system’ or ‘the application’ and you have to write grotesque code to make it work under the covers. This doesn’t make Cucumber a bad tool, just the wrong tool for the job of designing code.

So what is the output of BDD: User Acceptance Tests? Functional Tests? Unit Tests? System Tests? A system design? The design of individual units? It depends on who you talk to.

I’ve seen specs that are written from a customer point of view, useful as user acceptance tests. I’ve seen these mashed until they talk about an application in terms of controllers and pages and objects, making them useless as user acceptance tests because they’re not what the user agreed to and they no longer understand them well enough to re-agree to them. They’re also sub-optimal as drivers for design because they’re based on the implementation assumptions of the end user and they’re constrained to be about the subject matter that the user was originally talking about. This leaves lots of areas undefined where you need design but don’t have explicit user requirements because they just want it to work. The users will not tell you that they want to ensure that you have properly nested resource de-allocation blocks in your JDBC code because that’s not their domain. Do you need to have it? Yes, absolutely. Do you want it to work every time. Yes, absolutely. Will a badly designed solution make your code a pain to work with forever, yes absolutely.

So what happens? Developers have to write more specs, for things that users actively don’t want to know about.

I’m not convinced by BDD as a means of writing functional specifications either ( this doesn’t include User Acceptance Tests ). The best functional specs I’ve seen were elegant documents that used text, screenshots, charts, tables, diagrams, flowcharts and even embedded sound files to describe as concisely and accurately as possible the users expectations. Constraining these documents to a structured textual format is, at the moment, a bad idea. We’re reinventing Knuth’s Literate Programming ideas of the seventies, only we’re trying to impose it on clients and analysts too. There may be a future here, but I don’t think we’re here yet.

Particularly egregious offenders here are those cases where the functional specification is written in embedded strings in a document that is otherwise code. Conflating two completely different documents, and levels of abstraction into a single chimera-like whole that serves nobody well.

Ten years ago, I worked for a company where all development was done in UML and we forward generated the code from our diagrams. This didn’t work well, it was slow and painful but ‘technically’ it was possible so those in charge kept pushing the idea. Writing functional specifications using BDD frameworks is ‘technically’ possible but that doesn’t make it a good idea. Not here, not now.

We’ve learned new ways of building tools, and we’re looking for ways to leverage them. BDD isn’t AN answer, so it certainly can’t be THE answer.

I just followed a link from Ralph Johnson’s blog to a presentation buy Guy Steele called Growing a Language. I’ve seen links to it for years but never taken the time to watch it. I wish I had.

Everywhere I go, I see the same thing. “The best way to avoid swine flu is to wash your hands after you go to the bathroom.”

So, if this advice were to be believed, the source of swine flu is one’s own genitals. This does not seem likely. I don’t understand why seemingly rational, intelligent people keep stating this again and again as if it made sense.

My penis is not the source of swine flu. If my penis had swine flu, then I’d have swine flu. I cannot catch a disease from myself.

When I say I can’t understand why smart people would relay this same, obviously bad, advice again and again I’m really lying. I can understand it. There’s a whole host of reasons but mostly it is people attempting arithmetic with small numbers and failing.

1. I should wash my hands after I use the small room
2. I touch lots of things with my hands and so they are a significant vector of infection

Washing your hands may be able to help reduce your chances of catching certain ailments. Or it might not. But it has nothing to do with making use of the WC.

Sadly this sort of conflation of ideas happens all the time in the programming world. People take some idea that seems reasonable, toss in a dash of something else reasonable, shake and concoct a third thing of ‘limited utility’.

Looking for an example: well, take much of BDD for a start.

BDD = Penile swine flu.

I’m just going to leave that hanging there for a day or so whilst I write up my thoughts properly.

David Anderson’s InfoQ talk on Kanban and software development is fascinating. In particular I liked the clarity of the numbers he produced to prove the successes of his methods. I also liked the photographs of the tracking boards that different groups were using, David’s analysis of them and the way they changed over time as groups came into contact with each other.

All in all, a thought provoking presentation that backs ideas up with concrete numbers.

I’ve been a fan of Ruby for a long, long time. If I had a real world problem to solve, and language was no barrier .. I’d probably choose Ruby, unless there was a solid reason not to.

Why then do I spend so few of my hacking hours poking at Ruby code?

I think it is because my hacking hours are spent twiddling with new shiny things or working through the same old exercises[1] in different ways, rather than trying to achieve something. As I mentioned a few days ago, I think it is irresponsible and unfair to release an app or library to the OS community unless you’re willing to support it, and I’m not, so I rarely build big projects. For the most part, how I solve the problem is more interesting to me than the problem.

I suppose it comes down to - I rarely use Ruby because I’m rarely trying to solve a problem as efficiently as I can.

[1] Uncle Bob Martin’s “Agile Software Development : Principles Patterns and Practices” contains an interesting little console programming problem that I’ve worked through in half a dozen different languages.

I went indoor-climbing last night for the first time in over a year. Right now my arms hurt so much that I’d rather not have them. It’s not like they’re doing me much good just now anyway - my hands are largely incapable of closing and the opposable thumb seems like a dim and distant dream.

I did learn a few lessons last night, about climbing and about the way my mind works. When I arrived at the centre and approached the first wall, I realised that I had no idea how the equipment worked. I couldn’t remember how to tie myself on, and I couldn’t remember how to set up the belay end of the rope. That information had completely fallen out of my head. I’ve done it a thousand time but … I still couldn’t quite recall how to do it.

The bit I found most surprising is that I was sure I knew how, I was sure I’d forgotten nothing at all; right up until the point when I tried to do it. There’s a lesson there for all software architects (me included) - if you don’t write software regularly you will forget things about the process. Not only that, but you won’t know what you’ve forgotten. If you forget enough about the process you’re no longer an asset to your company. You’re just a guy who’s telling people how to belay, and keep other people alive, who can’t actually belay. Don’t be that guy.

My second lesson is about trust. I climb with my wife and my best friend. These are people I trust implicitly. I’d also given my equipment a thorough check over before I went out, so I was sure it was working fine. Even with that, I was terrified on my first few assents. Now, I don’t like heights, I hate them in fact. In the dictionary, under acrophobia it has a picture of me .. screaming whilst standing on a shoe-box. But I’d got over it whilst climbing, a year ago I could climb freely without fear. Now I was sweating and panting and wearing out my arms clinging onto the wall for dear, sweet life. Why?

To me, it seems that there are things that come naturally to us, and things that don’t. For me, being off the ground is not natural. By working at it, I got to a point where I was no longer afraid, then I began to enjoy it. At the same time it was good exercise that was helping me get a little bit fitter each time I went. When I stopped going, my confidence and trust in what I had learned started to erode and my natural fears and distrust started to come to the surface again. When we don’t practice something, we not only loose our understanding of it, we can start to believe things that are actively not true. Yes, brother architect, I’m talking to you again. Ever wondered why so many companies are lumbered with crappy products that the group architect purchased? Because they were out of touch, and began to believe the easy lies of silver-bullet vendors. They believed in the things that appealed to their core nature rather than the hard-won truths they’d struggled so hard to find.

When we don’t keep our skills sharp, we forget things. When we don’t practice our craft, we believe things that aren’t true.

After watching Dan Roam’s presentation, I decided to see what else looked good from Mix09. The day 1 keynote from Bill Buxton - available right now on the front page of the site gave me an insight into the mind of a designer that I didn’t have before.

Bill talks extensively about the history of industrial design and its rise during the great depression and that we can take the opportunities of the current financial crisis and use them to make usability design a priority.

I’m not sure if his logic, that crisis periods are inherently periods where design can prosper, is well founded but .. let’s hope it is. When you’re stuck in a financial hole, digging may not help but just sitting there doing nothing certainly won’t work. If innovative design and engineering can give us hope - let’s get to it.

Some of the ideas that Bill pushed strongly on were the notions that design has to be fast, has to be iterative and that only trying one approach to solving a problem leads to sub-optimal solutions. I’ve tried the first two of those ideas in development and they work like a charm. I wonder what it would be like to try to get several different solutions to the same problem in parallel? Perhaps that’s really what’s going on in the Java web framework world, or the .NET DI container world. Perhaps, rather than being frustrated by the problem of trying to learn and decide amongst multiple choices we should rejoice that we have options; we should be pleased that we get to choose the design that we believe in most.

The other big take-away that I got from Bill’s presentation was that in selling something you shouldn’t try to sell the item itself. You should sell the experience of using/owning the item. I can see this as a useful tool when trying to build software and also to make engineering decisions. Build software that will lead to a positive user experience and you’ll be a success. When considering two engineering alternatives, ask people to imagine the experience of living with that decision. Ask the technologist to put on his negative/remember-all-the-times-things-didn’t-work-the-way-they-should hat on and ask him to imagine what life would be like.

I’ve said it before, and I’l say it again. I love watching smart, passionate individuals talking passionately about their passions.

Mixing it up in Vegas: In this engrossing and entertaining presentation Dan Roam talks about his theories on sketches and how they unlock creativity and help communication and consensus gathering amongst groups.

I really enjoyed it, I’ll certainly try some of these ideas out, and I will probably buy the book. All those positives aside, three things do bother me about his presentation.

1. He starts off by saying that you don’t have to be able to draw at all to use his methods. That his ideas revolve around using simple shapes to communicate. Then he uses slide after slide filled with drawings that, whilst simple, are of a much higher standard than I could ever produce. (Yes I am that artistically challenged.) If simple diagrams are what you need to communicate .. why doesn’t he use any?

2. I’m willing to accept that using drawings as a means of communication engages parts of our brains that would otherwise lie dormant. What are the trade-offs? What are we sacrificing? Trading in my ability to logically critique something for my ability to create new ideas is something I’d want to do sometimes. When is it good, when is it not? Give me the down as well as the up.

3. I became suspicious when the Dan claimed that we can use pictures to solve any problem. That’s obviously nonsense. At best we might be able to describe any problem using pictures. Describing and solving are two different things. Don’t believe me? OK, well, all of my grandparents are dead. I love them, even those I never met. I’d like them back. Please provide me with the drawing that solves that problem.

Before I go any farther, I’d like to be clear that I’m a Black Pen Guy, When I talk, I like to stand in front of a white-board and scribble. I love to throw a marker to people and say, “show me what you mean”. Giving me a tool to make me better at design, communication and problem analysis is wonderful. That’s all you need to do to sell it to me.

Anyway, rants aside, this is a really interesting presentation with oodles of interesting ideas and anecdotes.

(Via Clarke Ching.)

I like the teams I run to use pair programming, because the end product is better. I’ve also heard lots of people say that they don’t want to do it.

I have a theory that pair programming is the brussels sprout of the technology world. Lots of people don’t eat them because, not because they think they’re bad for you, but just because they don’t like them

I have no children. When I do, they’ll eat brussels sprouts. I won’t do it because I want them to be sad, or to make those little sicky faces that children pull when they put something unfamiliar in their mouth. I’ll do it because I want them to be healthy, productive and to live a long time.

When I go to work I like to wear a suit. I also like to wear a tie. I like to wear thick, starched, stiff collared shirts with thick double cuffs. I like hard soled, thick leather shoes. I like to be aware of how I’m dressed, without being uncomfortable.

Why? It’s my war paint. In the same way that a Native American or a Massai tribesman or an ancient Celtic warrior put on face paint as a symbol that they were no longer at rest, they were now at war, and wholly committed to the task at hand. That’s how I want to feel when I go to work. I’m there, I want to get a job done. I’m committed. I’m not in the same frame of mind as when I’m at home with my wife watching TV.

Is it really necessary? Yes, for me it is. I like to make friends with the people I work with, the people I work for and the people that work for me. But friendship holds a trap. I’m not at work just to hang out and shoot-the-breeze. I’m there to create, to achieve and to add value. My war paint keeps me focussed.

I’ve been working on my CV recently and finding it hard to quantify what I do and am. I’ve worked in almost every capacity in technology:

• Developer
• Process Engineer
• Architect
• Team Leader
• Project Manager
• Analyst
• Product Manager
• Programme Manager
• Service Delivery Manager
• Support Engineer
• Agile Coach
• RUP Mentor
• Technology Evangelist and Trainer
• Trouble-shooter

And a whole bunch of other roles that don’t even have good names. I’ve loved every one of these roles, I’m fascinated with every aspect of technology. Beyond that, I like to flatter myself that I’ve acquitted myself well in all of these roles. I love technology, I love managing people. I love guiding and participation of the creation of something out of nothing. Well, nothing more than sweat, tears, inspiration and a compiler.

I’ve always loved the idea of being a polymath, a renaissance man - but sadly my interests have always been restricted to one field. Luckily it is a pretty big field and there are few people that have become masters of it all. I’m not there. Not even close. But I’d like to be.

Everyone needs a goal in life. “Be the best you can be at the thing you love” works for me.

Here’s a rule of thumb I like to use.

Q. How do you know when a document is too long to be useful?

A. Print it out and try to slip it under the door of the person you wrote it for. If it doesn’t fit … it’s too big.

As a an addendum to my test; whilst you’re at the door, open it, go inside, and say hello. Nine times out of ten, that’ll do more good than the document.

In a post entitled, simply, Software, Rafael de F. Ferreira juxtaposes quotes from James Bach, Erik Meijer and an Alan Kay/Phil Windley amalgam to put together an intriguing argument that quality software doesn’t exist, people no longer care that quality software doesn’t exist, computing is in its infancy and we don’t know much yet, but we’re also not really learning so things aren’t getting better.

I’m not sure I buy it. In fact I’m sure it is bunk. I’ve said for a long time that The Software Crisis doesn’t exist. As an industry we create more, better software cheaper than ever before. WTF is the crisis?

Can we do better? Yes.

So why do people talk about a crisis? Because programming attracts smart, dedicated, attention-to-detail-oriented, meticulous, perfectionists who’re never going to be happy. People who’re always going to want to do better. For many people - including me - software is my art, my hobby, my career, my passion. I want it to be great. I won’t accept second best. I won’t accept shoddy or badly done or half-hearted. I want to build the best .. whatever the hell it is I’m working on.

Equally, I won’t accept people telling me what a bad job the software industry does any more. We don’t do a bad job, we do the best job of writing software that anyone ever has in the history of the world. Possibly the universe.

Can we do better? Yes. Can you beat me with the crisis stick? No, sir, you may not.

My good friend, Clarke Ching, today proposed that we reach out to universities and colleges to help them teach students the things we’d like them to know when they graduate. I’ve done some of this in the past working with universities and colleges in the US and the UK, it was very rewarding. I’d love to do more.

Bob Martin has a presentation he gave at a JAOO conference up on InfoQ. The title of the presentation is Craftsmanship and Ethics, which is somewhat misleading since the presentation is basically on Software Craftsmanship prefixed with “we should be craftsmen, craftsmen should have ethics, it’d be unethical not to”. I was a little disappointed by that - I was interested in his thoughts on ethics and how they relate to the development.

Overall it is an entertaining presentation that will leave the Agile and SC groups nodding and leave those with a different mind-set shaking their heads as normal. I enjoy watching passionate people talking passionately about their passions… so this was fun; but I don’t think it changed any minds or taught anybody anything they didn’t know.

I’m assuming that the crowd at a JAOO event is composed of experienced professionals who care about and investigate their industry. To effect change it isn’t enough to speak passionately. It isn’t enough to tell experienced professionals what you think or feel - they have their own thoughts and feelings and there’s no reason they should supplant their own with yours. People need compelling reasons to change, they need people to provide compelling solutions to immediate problems, they need to believe that by changing they are shedding risk rather than increasing their risk profile. Passion isn’t enough.

Uncle Bob, and the other leading figures in our profession have the opportunity to speak directly to thousands, indeed millions of developers each year, and I don’t think that what they’re doing is working. The Tony Robbins style pitch is enough to get people fired up at the conference, it doesn’t carry enough momentum to provide a solid take-home.

I’m reminded of Geoffrey Moore’s Crossing The Chasm: Agile, Lean, Craftsmanship, all these ideas have been sold to the innovators and perhaps even the early adopters, we need to cross the chasm to get to the next group of technologists - the early majority. Even this isn’t enough, though. We haven’t got the message through to project mangers, business analysts or customers, let alone C*O types. We can present compelling cases when we talk to people one-to-one, but the ideas haven’t taken root in these communities; in Chasm terms we still don’t have a hook in the innovators there.

If we advanced the management and technology communities in parallel we’d have a much better chance of improving the way software development is done.

How do we do it? Well, first off, I think we need to stop talking about quality, top talking about Agile and Lean and Craftsmanship and start talking about value. Value is what everyone wants. Developers want to create value, managers want value created, customers want to buy valuable software.

I firmly believe quality leads to value, but telling people they should want quality leads nowhere. Tell someone they want value and they retort, “Of course I do, how do I get it?”. NOW you can say, “Well, every industry in the world has come to accept that building in quality leads to higher value.” At this point, I’ve never heard anyone say, “Hmm, that sounds hokey. Go build me some shit. I’m sure that my best path to value is by heading through latrine-town.”

When technologists, managers and customers talk about value, they may not all understand it in the same terms. At least not at first. But until they agree on what value is, there’s no way to build successful products or relationships.

The idea that people might not have the same understanding of value is something that many technologists don’t get right off the bat. To explain it, I need to take back something I said a few lines ago. I don’t believe that quality always leads to value. This also brings me back to Uncle Bob’s talk.

I have worked in environments where financial opportunities would arise out of nowhere, last for a few days or a couple of weeks and disappear. In these cases, the opportunity to make millions of dollars a day can exist if you can(in abstract terms) get information in, process it and send it back out within a specified time period. Oh, and the countdown on how long you can do this for has already started. Every moment between now and shipping costs a non-trivial sum of money. In these cases, value comes from shipping. The software might have problems - if it crashes every fifteen minutes night and day, that’s OK .. we’ll run ten copies on ten machines and have ten interns sit and watch them clicking the icon every time it falls over. The software doesn’t have passwords or security, that’s OK we can hire a rent-a-cop with a gun to keep people away from the computers.

Overall, doing this makes money. Sure, over the first few days the team try to improve the quality so that half the interns can go home - but the software is going in the bin in a week .. improvements beyond basic stability are a drain on assets nothing more.

I’ve heard developers shout about this being a terrible, shoddy way to do software and insult the developers who build it. I may even have been one of them. That’s because I wasn’t thinking about generating value with my software, I was only thinking about software for the sake of software.

Now I think about value, I can understand why people build software like that. I can also understand that we can get that software out of the door faster by looking at what we build in each case and trying to pull together some pieces that they can glue together the next time an opportunity arises. Pieces that’ll let us be EVEN faster to market next time. That’s value.

My point, value isn’t a universal truth. Value is relative to the situation. If everyone talks about value at the start, and forms a common understanding we can fit everything else into the framework this gives us.

Uncle Bob, luminaries of the development world, talk about value. Please.