Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Future of software development - Danger of Oversimplification

319 views

Published on

A talk that was given at the Servoy World conference https://servoy.com/servoyworld2017/ on some perspectives for the future of the software development industry

Published in: Software
  • Be the first to comment

Future of software development - Danger of Oversimplification

  1. 1. Perspectives on the Future of Software Development Jon Ruby Managing Director Jonar ServoyWorld, May 17th, 2017
  2. 2. Disclaimer • What follows are musings on the future, there is no certainty • There is value in discussing these things, that’s how we improve • This is not an attempt at providing a recipe for how to build and operate software companies • Not doing any product demonstrations, ask me later if you want to see stuff
  3. 3. you may know me from such talks as…. the difference between: users people
  4. 4. Swimming upstream is bold… unless the stream is a tsunami, then it’s just ridiculous • About 2.5 million scientific studies are published annually http://www.cdnsciencepub.com/blog/21st-century-science-overload.aspx • Too much to process or care about • Enter the media…
  5. 5. We love “Easy” • We are obsessed with shortcuts – Acronyms (KISS, USP, ERP, 3GL, B2B) – Infographics – Short, numbered lists: – 7 habits of highly effective people – 3 simple rules to have a happy life – All knowledge available onYouTube in “HowTo” videos • Can be great – Rapid acquisition of information – Highlighting relevant learnings without useless labour – Experts can guide our learning more easily – A theme can be more easily understood than piles of data
  6. 6. Sometimes, simple just doesn’t cut it
  7. 7. Is this too much of a good thing? • Clichés, metaphors, mantras and simple manifestos are great for making a point • Best practice is a GREAT tool but • It can’t be the only tool we use…. And we can’t use that tool blindly
  8. 8. Why does any of this matter to us? We make software, not national policy In software, we have clichés and mantra’s too…
  9. 9. SPLIT UP BIG SCARY PROJECTS INTO SMALL MANAGEABLE PIECES IN ORDER TO SUCCEED
  10. 10. …except while creating your backlog you died. Problem #1 Paint is peeling Problem #2 Curtains are missing Problem #3 Pipes have burst Epics and user stories to the rescue Painfully. In a fire.
  11. 11. Users report problems. Engineers fix them. 1. As a user I want the ability to add a GL Account to a line item on aVendor AP Invoice 2. As a user I want to know if the goods the invoice line is for have been received yet 3. As a user I want to know which specific record ID tells me the goods from the invoice line has been received 4. As a user I want to know if I have returned any of the goods that a particularVendor AP Invoice is charging for 5. etc… to infinity Should these be addressed with one user story each (UX dies fiery agonizing death), or a designed approach that handles them all with the same solution? Who watches over the total user experience?
  12. 12. MINIMUM VIABLE PRODUCT
  13. 13. Specialization • It is better to go to market faster with a smaller list of independent requirements met… sometimes • You end up with zillions of lovely little independent apps, none of which handleALL of what people need to do But that’s no problem, we have APIs!
  14. 14. Case study: Quickbooks Online and Trade Gecko integration “Everything was fine and then one day my transactions stopped moving from Quickbooks toTrade Gecko. I spent days even weeks with them on the phone trying to figure out what was wrong.They each blamed the other and nothing got fixed. It turned out Quickbooks changed their API and the engineers atTrade Gecko hadn’t quite finished updating their integration yet, but no one in service knew that yet.” –Irene de Gooyer-Collins (user in 2016)
  15. 15. FAIL EARLY
  16. 16. Fail Early • Not being afraid of failure is one of the greatest things we can instill in our teams • But it doesn’t always apply • Building devices for surgical operating rooms to prevent drug administration errors – Failure (early or late) isn’t really an option – In fact, the iterative process is actually dangerous Who’s this guy?
  17. 17. So what’s the message? • Am I advocating abandoning Scrum, Agile, Rapid Application Development, RESTfulAPIs or any of the smart simple tools we use in software development? NO! • I am saying we saw a problem and everyone moved to the left side of the boat, to the exclusion of all else • There are other tools out there as well and we can’t ignore them in in our pursuit of easy answers
  18. 18. The Future of Technology is People… I think • Users have infinite needs and requirements • People like technology that: – Just works – Does what they expect it to – The way they expect it to be done – Doesn’t require them to understand a secret language of jargon “Technology that appeals to People will always beat out technology that appeals to Users” -Jon Ruby (unproven assertion)
  19. 19. But you can’t please all of the people all of the time • Nope, but you can’t give up trying • It is not easy • You will get it wrong along the way.A lot. • There is no meaningful list of 5 or 7 or even 12 rules you can follow to be successful • There are however stories, experiences, lessons that we can learn from that will guide us along the way If this is so hard, is it even achievable?
  20. 20. Case study: Why do so many people like Apple products so much? • I think that it is because of UX and design harmony • If there were no logo on an apple product would you still be able to identify it as such?
  21. 21. What are the takeaways? • You need someone to constantly keep the big picture in mind. Someone that understands people and technology – That’s not exactly achievable nor scalable even if you do find one person. – Answer: culture • Take the longer view while still being willing to fail in the short term – Nice in theory but it can become financially untenable – Answer: think of capital and finance like the water you will need on a long difficult journey • Chasing Unicorns is a sucker’s bet – Attempts almost always fail – Failure is almost always complete – Even success rewards a very few within an organization, and not always the most deserving (guile often trumps contribution) – Answer: focus on what really matters
  22. 22. Culture • Everyone has to challenge everything • Leave your ego at home • Forget a lot of what you know about management • Before you can learn to treat your users as people you have to learn to treat your employees as people • People are mostly not motivated by money, you can’t buy them with cash
  23. 23. Capital • More money early is not always better • The right money at the right time in the right amount is great • Figure out how to get it and when you will need it as early as possible • Wait to take it as long as you can, but don’t wait too long • Specific suggestions: – Wait until you have something that you can realistically accelerate at a decent quality level before you give up significant control – Figure out the profile of investors you want and then figure out what they are interested in and then make sure you are appealing before pitching them
  24. 24. Beware of chasing Unicorns • Build solid foundations instead of rushing into get rich quick schemes – Yields: • Better teams with happier people • Better quality technology that is more appealing to people • More stable and robust returns allowing growth and longevity
  25. 25. success /səkˈses/ noun 1. Paragon is what people are really, truly looking for 2. Very valuable technology asset that is saleable 3. An amazing team that can be targeted at any project 4. Zero debt and enough capital to try again Perception is perception. Reality is reality. • Not certain yet if my pontification is totally accurate or whether our project will be a big success • Even if I’m wrong its been a hell of a ride and we have ended up with
  26. 26. Done it all by refusing to accept the over- simplification

×