Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Quality versus-speed-tradeoffs
Ähnlich wie Quality versus-speed-tradeoffs (20)
Mehr von Andy Marks
Mehr von Andy Marks (17)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Quality versus-speed-tradeoffs
- 1. Quality versus Speed Technical Decision Making for Startups
- 2. • Quality/Speed tradeoffs • Technical debt • Architecture • Hints & tips
- 3. Can you tradeoff l a t rn e quality for speed? i n
- 4. No.
- 8. Impact
- 9. Measurement
- 10. Measurement
- 11. Measurement
- 12. ARCHITECTURE
- 13. What is your architecture?
- 15. HINTS & TIPS
- 16. Value (using) libraries over frameworks
- 17. Value anything over building frameworks
- 19. Value Automation over Manual
- 20. Value Functional Tests over Unit Tests
- 23. Value just-enough over kitchen sink
- 25. @andee_marks
Hinweis der Redaktion
- Welcome\nTW background\nDilemma question\nCorporate experience -> Lean Startup + Echelon\n\n---\n\nGood evening everyone - thanks for coming along tonight. My name is Andy Marks and I work for a company called ThoughtWorks. We specialise in custom software development and the core practices around this activity, including Experience Design which is what my colleague Xiaodan will be talking about later this evening.\n\nI'm here tonight to share my opinions on one of the dilemma questions I believe many startups face in their desire to get to market as quickly as possible: what impact does software quality have on ability for a startup to deliver a working product quickly.\n\nNow at this point I should say that I’ve had lots of experience talking about these topics but many of these conversations are usually had with enterprise and corporate IT groups. So I basically had a leap-of-faith assumption that my experience in this area was transferable to startups. Thankfully a prime opportunity to get some validated learning under my belt came around at Echelon on Monday and Tuesday. Everything I heard and everyone I spoke to about the role of software quality in the startup scene reinforced my existing beliefs around this topic. \n
- There are four main things I want to cover tonight. The first one is the main topic, but in order to give it justice I cannot avoid introducing and describing Technical Debt and the place software Architecture has within startups. Finally because I’m going to be speaking at a reasonably high level for most of this chat, I wanted to leave you all with some more specific actionable advice. Now, I cannot guarantee that each and everyone of these Hints and Tips will be eye-opening revelations, but I do hope that at least one of them will be useful for each of you. \n
- Original proposition\nINTERNAL quality\nDefine internal vs external\nThe answer is...\n\n---\n\nSo let’s get back to the original proposition...\n\nCan you tradeoff internal quality for speed? Note than I’m limiting this discussion to internal software quality. As many of us will be aware software quality has two aspects to it; (a) the external quality - that which is observable by your customers and end users (b) and the internal quality - how the software is designed and architected to deliver the external facing functionality. \n\nTo which the answer is...\n\n\n
- “Cannot”\nAbrupt end to convo\n+ more ambiguity\n\n---\n\nAlthough that seems like an awfully absolute and abrupt end to the conversation (and I still have some time left) so let me put a bit more ambiguity around the situation.\n
- \nDesign Stamina Hypothesis\nDefine Design\nRead the article\nBlue line\nRed line\nTipping point\nHypothesis - not proven, but axiomatic [STRONG]\nWhen is tipping point?\n\n---\n\nThis is a graph from an article written by another ThoughtWorker called Martin Fowler titled the Design Stamina Hypothesis. I heartily recommend you read this article when you get a chance, but I’ll extract the key elements for now.\n\nThe central premise behind the hypothesis is that there is mathematically a tradeoff point where spending less time on software design (internal quality) does provide increased speed. This is shown by the blue line. However there is a tipping point where consistent attention to internal quality (the red line) will result in a more maintainable codebase which enables faster delivery. This is where the red and blue lines intersect. From that point onwards investment in internal quality increases the speed of the team relative to the no design approach.\n\nNow as Martin himself recognises, this is truly a hypothesis as it has not been proven empirically, but I’ve yet to meet many developers who don’t instinctively understand these curves and their impact.\n\nSo the big question is - at what point in time on the X axis is this tipping point? Again, this is a hypothesis, so I cannot give anymore than a strongly correlated group opinion but I would strongly urge you all to be thinking a matter of weeks rather than months.\n\nWith that in mind, it does open up the options for startups to consciously sacrifice internal quality if they have an impending date in the very near future that they need to meet. Now this is not a decision to take likely and not one to take without understanding the consequences, but I believe the judicious use of this approach can be useful from a business perspective to hit crucial deadlines in upcoming weeks. \n\nThink of it as you hopefully do a big night out. Once in a while you can stay out to the wee small hours and be reasonably productive during that time. But for the vast majority of us, this is not a sustainable practices as the payback for such planning is usually only one sleep away.\n
- There are variations around this quote - “go slow to go fast” is another popular one, but the main idea here is that for a software development group to be able to execute quickly, they often need to perform what might seem like counterintuitive tasks which seem at best tangential to the process of delivering functionality.\n\nBut before we look at some examples of what I mean by this statement, let’s revisit our original statement...\n
- #1 topic around software quality\nName checked by Brian Wong\n\n---\n\nWhich brings us nicely to the number one idea around managing software quality - Technical Debt. This was a topic that was name checked by Brian Wong at Echelon but explored no further, so I’ll dig in a little for those of you who aren’t familiar with the concept.\n
- Ward Cunningham - 20 years ago\nCut corners -> debt\nInterest payments - slower pace\nPay principal - fix the root cause\nFinal option - bankruptcy\n\n---\n\n[Who hasn’t heard of, or only has limited understanding of the idea of technical debt?]\n\nThe metaphor was first coined by a software engineer called Ward Cunningham and is now 20 years old.\n\nThe basic idea is that when you cut corners on internal quality you are taking on a debt of a technical nature because you are leaving your codebase in a state which is harder to maintain.\n\nAs with all debt, there are interest payments you need to make - this is the slowdown that the team experiences when working with the codebase. You can choose to continue to pay only the interest on the debt by continuing to work slower, or you can choose to repay the principal of the debt by going back to the parts of the design you ignored and working on them. \n\nTechnically, there is one further option which is to ignore paying off either the interest or the principal. With technical debt, as with financial debt, the end game of this path is bankruptcy, or the inability to do anything with your assets.\n
- More Martin\nOther causes of technical debt\nNot 100% agreement re: Inadvertent\nImpact is the same\n\n---\n\nThis is from another article of Martin Fowler’s and it describes some other reasons for teams taking on technical debt, beyond the conscious and calculating option I proposed earlier, which is represented by the top right hand of the quadrant.\n\nNot everyone agrees that the two Inadvertant quadrants are legitimate forms of technical debt, but IMO it doesn’t matter too much how or why the debt was incurred, the impact on the team is the same, as are the options for addressing it.\n
- Impact - speed\nNot just straight line\nImpact - steering\nAbility to pivot\nUnless...\n\n---\n\nAnd speaking of impact, one of the biggest impacts is on the ability of the team to delivery software quickly. But it’s not only straight line speed which is affected. High levels of technical debt also impact steering as well. Code that is difficult to work with is difficult to change, let alone augment, so if you need to pivot your product, that process is also going to be more costly and less effective, unless the pivot results in the entire codebase being thrown away, in which case the technical debt goes with it.\n\nImagine if you’re designing a car and your assured by the product owner that each car will never need to turn, never need to change direction once it’s started on it’s initial course. Think of the savings you could make working under those assumptions! Think of the elements of the car that would be needed if it didn’t have to do anything but go in a straight line! No steering wheel, no indicators, no differential, no power steering, no rack-and-pinion stuff.\n
- Control TD - start by managing\nTo manage, start by measuring\n[*] Measure - software tools\n[*] Measure - visual tracking smells\nLooking for CTO? Make sure they understand\n\n---\n\nThe key to controlling technical debt is to manage it, and a very helpful way of managing it is to start measuring it. Either by using the vast army of software quality tools that are available for most popular languages or by allowing the team to visually track where it thinks the smelly parts of the codebase are.\n\nIf you like, you can treat the level of technical debt in your codebase as a hypothesis in the Lean Startup sense and devise tests to assess whether you (as the customer) are happy with the level of design. Keep running those tests as frequently as possible to keep a handle of the level of debt.\n\nIf you’re a Founder looking for a Technical Co-Founder or CTO, you want to make sure potential candidates understand these tradeoffs quite well and also the impact of technical debt on a codebase.\n
- Control TD - start by managing\nTo manage, start by measuring\n[*] Measure - software tools\n[*] Measure - visual tracking smells\nLooking for CTO? Make sure they understand\n\n---\n\nThe key to controlling technical debt is to manage it, and a very helpful way of managing it is to start measuring it. Either by using the vast army of software quality tools that are available for most popular languages or by allowing the team to visually track where it thinks the smelly parts of the codebase are.\n\nIf you like, you can treat the level of technical debt in your codebase as a hypothesis in the Lean Startup sense and devise tests to assess whether you (as the customer) are happy with the level of design. Keep running those tests as frequently as possible to keep a handle of the level of debt.\n\nIf you’re a Founder looking for a Technical Co-Founder or CTO, you want to make sure potential candidates understand these tradeoffs quite well and also the impact of technical debt on a codebase.\n
- Next: Architecture\nCorporates - over architecting is issue\nStartups?\n\n---\n\nWhich brings us nicely to the idea of Architecture and how that fits into the technical vision of a startup. Again, I spend a lot of time trying to stop large corporates commit technical suicide by way of architecture. However, whereas they are more likely to over-architect than anything else, I suspect that doing not enough thinking about design or architecture is more of a startup issue.\n
- Every app has architecture\nSum of key decisions\nDon’t need to use work or role\nImposed architecture through frameworks\nLot of heavy lifting is done - solved problem\nWont suit everyone, but fine for most startups\n\n---\n\nI think this is an important question because it points to the fact that every application, every codebase has some underlying organisation to it, some general way in which the component talk to each other. There are some key technical decisions which need to be made to allow development to begin and continue. The sum of these key decisions is effectively your architecture. It doesn’t matter if you don’t ever use that term to describe your codebase. It doesn’t matter if you don’t have anyone with that role in your startup. Your codebase has an architecture, whether or not you actively do anything about it. For many of you I suspect your prevailing architecture will be the one imposed upon you by your main development framework; Django (Python) or Rails (Ruby) or YII (PHP) and deployment platform; Heroku for example.\n\nAnd one of the great things about the fact that there is such widespread acceptance of these frameworks and platforms means that some of the heavy lifting around defining key elements of an architecture has become a solved problem. True, these commodity architectures aren’t going to suite organisations that require the scale of any of the high profile Web 2.0. companies, but for startups they should work just fine.\n
- Still non trivial amount of design needed\nAdvice (shoulders of giants): evolve the design\nWait and learn: customers, market, etc\nLonger you wait - more context is generated\n[Analogy around how much upfront design to do]\nLean Software - has term\nInspired laziness\n\n---\n\nBut regardless of how much of your design has come out-of-the-box as a result of the existing software components you are leveraging, there will still be a non trivial amount of software design or architecture that needs to be done for any startup. My advice (and again, I’m standing on the shoulders of giants to give this advice) is to let your design evolve as you learn more about the problem you’re trying to solve, more about your market, more about your customers, what they want, what they don’t want.\n\nThe Lean Software Engineering movement has a term for this approach to decision making in general - the last responsible moment. Used a philosophy of inspired laziness to delay and put off key decisions as late as possible. Again, this may seem counterintuitive for some, but it should result in a better opportunity to make decisions.\n\n
- The future is a very tricky thing to predict, I’m sure you’ll all agree. Another axiom about decision making is that the longer you can comfortably wait before you make a decision, the higher quality that decision will be when you make it because of the extra context you will have generated over that time.\n
- Lean Software - has term\nInspired laziness\n\n---\n\nThe Lean Software Engineering movement has a term for this approach to decision making in general - the last responsible moment. Used a philosophy of inspired laziness to delay and put off key decisions as late as possible. Again, this may seem counterintuitive for some, but it should result in a better opportunity to make decisions. \n
- Actionable Advice... with caveats\n\n---\n\nAnd I did promise some actionable advice, so here we go. Again, I’ll make the caveat that as soon as you get specific, you risk saying stuff which is either not applicable to some people or something they’re already well aware of, but so be it... \n
- Frameworks generally useful\nStay within the sweet spot\nFramework for most stable parts (e.g., web application)\n\nLibraries - less opinionated\nLess constraints\nOther code -> your code: framework\nYour code -> other code: library\n\n---\n\nSo I mentioned before about the prevalence of frameworks like YII, Django and Rails, but an over reliance on these things can be a source of pain in some circumstances. Provided your application does hit the sweet spot of the framework, things are generally rosy, but as soon as your requirements take you to places not ever imagined by the framework’s creators, you can be in a lot of trouble as you try to code around the framework to meet your needs. Generally speaking, you should choose a framework only for the most stable aspects of your system, which is why Rails, etc are so popular because it’s rare that people start out building a web application and find that the MVC model Rails mandates isn’t really what they want.\n\nLibraries, by way of contrast, are generally far less opinionated in terms of there usage and place less constraints on the developers’ than frameworks. If you want to quickly know the difference between the two, it’s quite simple: if your code calls the other code, it’s being used as a library, if the other code calls yours, it’s being used as a framework.\n
- No right!\nProduct is framework?\nInternally pivoted away from customers\nSome developers - premature generalisation\nEvolve frameworks - and leave it to someone else\n\n---\n\nStartup technical teams have no right or time to be building frameworks of their own IMO. Unless your product itself is a framework, as soon as you start thinking about building a framework you’ve internally pivoted the direction of the codebase. Unfortunately, some developers love this sort of stuff and are struck by that most cruel of diseases: “premature generalisation”. The only valid way to build frameworks is to evolve them from within working applications, and usually only after you’ve written those applications enough times to see that there is legitimate re-use opportunities involved.\n\nFrameworks - use them if you have to, don’t build them, certainly not when you have a product to focus on.\n
- Future world - polyglot persistence\nShort term - NoSQL good for domain model evolution\nRemoves most of cost of managing schema\n\n---\n\nI’m not a believer that NoSQL databases will replace traditional SQL databases in all applications. I see a future where polyglot persistence becomes the norm, where applications use a variety of relational and other models based on “fit for purpose” criteria. In the short term though, evolving a domain model for your application is not an easy activity and it usually takes quite a few cycles to get right. For these reasons, using a NoSQL database can free you a little from the overhead of managing a dynamic schema and will allow a technical team to more a little quicker during these formative days, weeks and months.\n
- Setting up a development environment for a new person on your team - one click\nDeploying your application to production - one click\nMigrating your production database into a test environment - one click\nAnonymising that production data - one click\nScaling out/back your fleet of servers to handle changes in traffic conditions - at most one click \nRolling back a deployment - one click\nVerifying your application is behaving correctly and hasn’t suffered any regression issues - at most one click\nCapturing key metrics for your application in production - zero clicks.\nDevOps Singapore!!!\n\n--- \n\nAnd if I can shamelessly self promote for a second, I run a user group in Singapore called DevOps Singapore which focusses almost exclusively on these issues if you’re interested.\n\n
- Never go without automated testing\nUnless no manual testing at all\nGood tool maturity in likely languages\nGun to your head: Func > Unit\n\n---\n\nI should potentially have spent a bit more time talking about this earlier but there is one thing I don’t think any startup can do without for any period of time and that is automated testing of the functionality provided. Unless you are planning absolutely no manual testing of any kind during development, then there is really no additional cost to doing some level of automated testing and all the languages you are probably using have some level of maturity around the automated testing tools they provide.\n\nThat said, not all automated testing is created equally and if you have a gun to your head, I would favour testing of the external functionality of the application over the internal functionality using unit tests. In reality, experienced automated testers will do both as a matter of course, but if your team doesn’t have that level of experience, please do at least spend some time automating the main workflows of your application to ensure no regression occurs. \n
- ---\n\nFor the vast majority of startups, the ready availability of virtualised servers in the cloud have greatly lowered the barrier to entry. There really is no need to use traditional data centres in the early stages of your startup until you have proven your business model and likely traffic needs. The setup costs will quickly consume any lose cash you have lying around.\n\nI doubt anyone here is using colocated data centres at all anyway. \n
- Heroku > AWS\nAWS will make sense in the future - not now\n\n---\n\nLikewise, unless your product demands it, Platform as a Service providers like Heroku should be a compelling idea for startups when compared to rolling your own platform via Infrastructure as a Service providers like AWS. There will probably come a time when the Herokus of this world dont provide the configurability that your product may need, but if you’re looking for speed then PaaS will do just fine.\n
- Hidden technical debt in unused features\n\n---\n\nAnother niche form of technical debt is the usage of software components where you only need a fraction of that components’ functionality. Don’t think that just because you’re not availing yourself of 50% of the features of framework X that those features are not causing some drag on your team by the mere fact that they could be the source of defects or updates to the framework that you don’t really need.\n
- So here we are at the end. I hope there was at least one thing in the Hints & Tips for everyone here. \n\nI’ve covered four main areas around the interplay between speed and the internal quality of codebases. My original assertion that there is very little opportunity to sacrifice the former to optimise the latter still stands. It’s not quite a false dichotomy, but it’s at best a mostly false dichotomy. Make haste slowly by making sure your internal quality is permanently cared for by a team which understands how to do so. \n
- My name is...\nI work for...\nI am interested in DevOps\n