Posts filed under 'Software development'
Enrich, Simplify
The Gaping Void cartoons are often really spot on, and here’s one of my favourites.
It neatly sums up something I’ve struggled with in my life developing software products over the past 10+ years. Programmers will prefer to continue building software (development) rather than slowing down and seeing how people use that software in the real world (support). So you often see a tendency to continue adding new features one on top of the other. Something that used to be good once gradually becomes more complex and brittle over time.
Where I am now I try to develop products along the lines in the Hugh cartoon. Deliver software in small chunks. Speed up and slow down delivery so that you have time to see how people use your latest code before you race off down the next avenue. Focus on the pieces that people are interested in. Spend time stripping stuff out as much as piling new stuff on. Depending on what the user base really uses. Something that is only really practical in the On Demand/SaaS/ASP/whatever world rather than the behind-the-firewall expensive-customised-software world.
Not a million miles away from the approach Mitch Free talks about in this interview with Jason Busch today (and what prompted this post).
Add comment July 10, 2008
Blame the users, or the technology?
Hardly a news story but this week’s Supply Management has a news story headline “Councils: most buying goals met“.
One of the goals listed in the article that was not met was the use of e-marketplaces.
Each council was also meant to be using an e-marketplace by 2006, but latest figures show only 22 per cent have met this target.
The traditional response to such a dismal failure to adopt a new technology is: “more change management, please, doctor”. As if the technology users are always to blame for being to blinkered.
But are people always and everywhere scared of new technology? I don’t think so. People are not afraid of adopting new technologies if those technologies are good. Excel. Mobile phones. SMS. Email. Social Networks. Online airline check-in. Google. Online banking. Etc etc. (yes, I am old enough to remember offices before Excel. I spent some time working as an accountant doing 4 column trial balances on paper. That was horrible).
Oh yes iPods. Good technology. Vista. Not as good technology.
You can make your own lists.
To come back to the SM article: if an e-marketplace helps buyers buy stuff better then of course they will use it. But if it is just a pain in the a** to use then they will stick to email and Excel. And don’t talk about nebulous downstream process improvements, puh-lease. People want process improvements now, not some unidentified time in the future.
When a fly keeps banging its head against a pane of glass trying to get out of your house, it’s obvious what the fly needs is a different approach: an open window. The same is true in enterprise software. Software developers: stop bashing your heads on the change management window. Do something to your software so the users don’t need change management to want to use it.
The exciting news is that there are some people who are daring to do the undoable. Thingamy for example has the audacity to be challenging not only the rigid process-driven ERP mindset prevalent in the industry, but also how we do something as basic as accounting. Will they succeed? Who knows. But the more people who take Sig’s lead and try to re-invent enterprise software, the more chance we’ll have of getting those buyers all happily using their e-marketplaces.
Add comment May 30, 2008
The Best Charts and Graphs. And Software Development
I love good graphs. Ones that take a whole morass of messy data and elegantly communicate something significant from that data. So I loved reading Edward Tufte’s “The Visual Display of Quantitative Information“.
He talks about some delightful concepts: “data-ink” (the ink that communicates the urderlying data); “chartjunk” (the crap on charts that distracts from the communication of the data); “lie factor” (the degree to which a chart distorts the underlying data). And there are some fun snippets: Plotting time on the x-axis didn’t start happening until the 1700s; China had accurate maps of its territory plotted on grids in about 1100 while Europe didn’t catch up for hundreds of years.
But the point of blogging it here is its twofold relevance to business technology:
1. Some of the trickiest questions in software design are around how to communicate information clearly without over-complicating or trivialising. (cf The Doctor’s comments on dysfunctional dashboards).
2. A lot of his advice applies equally to software development generally.
Here are some choice quotes:
Occasionally designers seem to seek credit merely for possessing a new technology, rather than using it to make better designs. Computers and their affiliated apparatus can do powerful things graphically, in part by turning out the hundreds of plots necessary for good data analysis. But at least a few computer graphics only evoke the response “Isn’t it remarkable that the computer can be programmed to draw like that?” instead of “My, what interesting data.”
and
The best designs are intriguing and curiosity-provoking, drawing the viewer into the wonder of the data, sometimes by narrative power, sometimes by immense detail, and sometimes by elegant presentation of simple but interesting data.
and
Graphical excellence is that which gives the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space.
and
Design is choice… The principles should not be applied rigidly or in a peevish spirit; they are not logically or mathematically certain; and it is better to violate any principle than to place graceless or inelegant marks on paper. Most principles of design should be treated with some scepticism, for word authority can dominate our vision, and we may come to see only through the lenses of word authority rather than with our own eyes.
and
What is to be sought in designs for the display of information is the clear portrayal of complexity. Not the complication of the simple; rather the task of the designer is to give visual access to the subtle and the difficult – that is, the revelation of the complex.
3 comments March 12, 2008
My First Reverse Auction
Yesterday I ran my first reverse auction for spend that I control and for a contract I will be responsible for implementing: Offshore Development Services. This was also TradingPartners’ first reverse auction for our own spend (rather than on behalf of a client). This was not a toy auction. This was a real auction for some spend that is very very core indeed to the company.
Auction setup
-
Reverse English Auction
-
Weightings incorporated into the auction on about 60% price, 40% non-price
-
Non-price was based on an assessment of things like: Size + Stability of company, Experience of similar projects, Quality of their ideas for enhancing the software, ability to scale the team, relevant certifications etc
-
Suppliers were able to see their price, how this converted to a score, and what the best score was. So suppliers could see how much they needed to drop their price to become best value for money overall. In other words they were genuinely bidding on a level playing field.
Auction results
-
I could see where a suppliers dropped out and so can have confidence that the price levels reached were
-
Savings were pretty impressive
-
A supplier I had thought was keen on the business did not bid as actively as I had expected.
-
Similarly a supplier I had thought of as an outsider came in with a very compelling offer.
No, I’m not going to tell you the baseline but feel free to drop me a line if you want to discuss the reverse auction more.
Some thoughts
-
Could I have done better off-line? No. In all my negotiations with software development companies, this was by far the best, fastest, and easiest.
-
Was it right to weight the auction? Absolutely yes. It was a little more work up front, and I nearly did give up trying to do it. I can see why so many buyers shy away from doing this. But I’m glad I saw the process through because it has given me a clear picture of where the market genuinely is and my work from here on is much much easier than it would have been otherwise
-
Would I do it again? Definitely. Some reasons why in a future post
-
I wonder whether buyers are unconsciously biased towards certain suppliers. For example, a supplier I had thought was very keen for the business did not really bid very seriously during the auction. Looking back at my previous conversations with that supplier I recall that they had evidently taken the time to read my blog and discuss the issues it raises with me, and I wonder whether that pre-disposed me favourably towards that supplier. Whereas, when you look at the market objectively through a reverse auction you see that there are probably other suppliers out there who are going to be better at delivering what you really need
-
Are the prices and offerings I have genuine? Have suppliers been gaming the system? Will I find them taking advantage of me later on? I hope not because the reverse auction was weighted to include our assessment of their non-price value-add. But time will tell.
I’ll let you know how I get on with implementing the contract.
3 comments January 9, 2008
Software Patents are a tax on innovation
It’s no secret that the patenting system, for software at least, is a mess.
I have talked to a number of entrepreneurs, CEOs, CTOs, and even Intellectual Property lawyers and have yet to come across any credible examples of where software patents have had a positive effect. Here are the reasons for taking out software patents that I have so far come across:
Marketing: Having a patent granted gives you something to talk about in your promotional material.
Sales FUD: Having a patent application in (not necessarily even granted) lets you talk bigger in front of prospects.
Because the VCs told me to: Investors may feel an exit will be more valuable if there are some patents amongst the firm’s assets.
For defence: If one of your competitors tries to screw up your IPO by threatening a patent infringement suit then you’ll probably find some way that they are infringing one of your patents and can beat them off that way.
IBM makes a lot of $$$$ by licensing their IP: By extension, so could you. If you wanted to operate that kinds of businesses.
Nowhere (or just incredibly rarely) does “to protect and reward the inventor” figure. Much innovative software is developed for free under “open source” (*).
Now look at the commentary on the Ariba/Emptoris pissing contest patent wars and tell me that someone other than lawyers benefits from this broken patent system.
http://www.combinenotes.com/site/comments/ariba_sues_for_patent_infringement/
http://www.spendmatters.com/index.cfm/2007/11/26/Patent-Suites-Continue-Should-Customers-be-Concerned
P.S. This tirade is just directed at patents. I suspect the solution to the IP mess might be addressable through copyright.
P.P.S. At TradingPartners we have taken the view not to apply for any patents. I’d prefer to spend the $$$ on building better e-auction software. If someone wants to rip us off then I’ll take it as a compliment, and it will just spur us to innovate harder.
(*) Setting aside for a moment the thorny issue of whether some open source code infringes on others’ intellectual property.
2 comments December 3, 2007
Coupa Geek Out Moment
Since my last post on Coupa I’ve checked the open source version of their software and am mightily impressed.
On the functionality side of things it seems to do 80% of what Ariba used to do when I was familiar with that application (admittedly, some years ago now). And the 80% it does is the important 80%.
And on the technology side of things I am blown away now by Ruby on Rails and Amazon EC2. Both are tremendous technologies to use - I can’t remember the last time I found a programming language (Ruby)/system environment (EC2) so exciting.
Time for a sit down I think before I get too carried away. I suspect Coupa will crop up in a few more upcoming postings here.
Add comment October 25, 2007
Product Development Lessons from Proctor & Gamble
Just been reading another article in the current issue of The Economist about Procter & Gamble’s approach to product development, entitled “Will she, won’t she?”.
Some quotes
[M]any people at P&G do not use the word “consumer”. Nor might they ask if a “customer” or “shopper” would buy a putative product. They are more like to ask: “Would ’she’ buy it?” … Women have long accounted for four fifths of P&G’s customers.
and
Staff from [P&G's] Consumer and Market Knowledge division tour the world and spend entire days with women to observe how they shop, clean, eat, apply their make-up or put nappies on their babies. They try to understand how a woman reacts in the first three to seven seconds after she sees an item in a shop (the “First Moment of Truth”, in P&G speak) and when she tries it at home (the “Second Moment of Truth”).
Some insights for those building enterprise software and esourcing software systems:
1. Be clear on who you are targeting. Certainly avoid generic terms like ”user”. A particular challenge for enterprise software developers is that the person buying the system (could well be a Purchasing Director or CFO, for example) is often far removed from the people who actually get saddled with the software. Which one is the real target? Probably both. Most enterprise systems I’ve seen are great for one or the other, but struggle at being good for both.
2. Once you’ve worked out who you are targeting get to know how they really operate during The First and Second Moments of Truth, i.e. When they see the demo (they first moment of truth) and When they pilot it for the first time (the second moment of truth). You won’t achieve this by reading analyst reports and case studies. You’ll only achieve this by being on the ground with people as they work with the software.
Add comment August 17, 2007
Users – smart or dumb?
Been on holiday for the past few weeks – the distance from work, and the clear blue seas, help give a new perspective on things.
One of these for me has been the common assumption techies have that users are fundamentally dumb. IT support people are well known for holding this view point. But then again, so do many software developers. For example, all those mega ERP-style systems that implement rigid processes assume that users can’t be allowed to think for themselves and that instead the system must do as much of the thinking for them as possible.
But the reality is that people are all actually pretty smart. If only technologists would start working from this assumption – assume that their users/customers etc are smart. If they can’t operate the technology then assume that it is the system that is dumb, not the users. This shift in mind set would not only help IT be seen to be more of an asset to the business (by reducing the amount of “them and us”), but would also allow technology to deliver more real value to the real users. Which after all is the point of technology in the first place, isn’t it?
Add comment May 23, 2007
It’s the data, stupid
Business 2.0 magazine has a feature on new occupations being created in the US.
My favourite one (apart from the Second Life lawyer) is the Information Engineer. As Web 2.0 companies like Paypal, Meebo and Slide find themselves increasingly awash with data they need people with the skills to be able to draw insights and conclusions from it (as opposed to people who just run reports).
What makes this particularly interesting is that data crunching has now been elevated, by the use of the word “engineer”, to the same level as the software engineers who write the actual code.
These companies are starting to see that the value is in the information, not just in the technology. Over time, the value of software itself trends toward zero, whereas the potential value of the information transmitted and stored by the software increases exponentially.
End users have always known this. People use MySpace or Facebook, not because they have the best technology, but because of who is already on it. eBay auctions are so successful because that is where buyers go to look for bargains, not because their auction software is the best.
In other words, here is another example that Web 2.0 is all about technologists catching up with what the users wanted Web 1.0 to be in the first place.
Add comment May 1, 2007
Participant Observation and Software Product Development
First of all there was the “them” and “us” of “IT” and “The Business”, the methodology of choice was Waterfall and IT’s job was to implement what the Business said it wanted. Projects were late, expensive and disappointed everybody.
Then came Rapid Application Development, DSDM, UML, Rational Rose etc. On of the big ideas here was to get “IT” and “The Business” into the same room so they could decide together what they wanted and hopefully come up with a better result. Thankfully it was better than the Waterfall approach.
Where next?
The next evolution, I hope, will be be building software through participant observation. Anyone who has done much product development will know that what people say they want is often very different from what they really want. And what they actually need is usually different still.
Participant observation would recognise that even when you get five people in a room together, what is agreed and written down by those five still stands a significant chance of not reflectng reality. The only way to really build software is for the builders to really know how the users will use the product. The only way to do this is to walk a mile in their shoes. Or, as a participant observer would say, to live with them for 18 months before you start writing a line of code.
Add comment April 27, 2007
