Recommended
More Related Content
What's hot
What's hot (20)
Similar to Software development in the modern age
Similar to Software development in the modern age (20)
More from Roy Wasse
More from Roy Wasse (9)
Recently uploaded
Recently uploaded (20)
Software development in the modern age
- 1. Software Development in the modern age An opinionated update on how to get it right
- 2. OPENVALUE GROUP Group of companies 100% specialized in Java Development. Organized in autonomous teams with offices in Utrecht, Amsterdam, Rotterdam, Munich, Düsseldorf and Vienna. Actively contributing to the international Java ecosystem through workshops, tech talks, training courses etc.
- 3. Speaker • Roy Wasse • Co Founder OpenValue • Former JUG leader (2013-2021) • Former Code Motion PC lead (2018-2021) roywasse https://www.linkedin.com/in/roywasse/ Img source: https://www.redbubble.com/i/laptop-case/I-Love-Software-Engineering-by-staker/23699211.2U5KG
- 4. The art of software development… • So many languages, tools, frameworks • How to organize a modern team? • How to make maintainable and adaptable software? • Cost effective? Img source: https://redmonk.com/sogrady/2021/08/05/language-rankings-6-21/
- 5. Programming languages • Github • Stackoverflow • Market Img source: https://redmonk.com/sogrady/2021/08/05/language-rankings-6-21/
- 6. Redmonk Q3 2021 Programming Rankings 1. JavaScript 2. Python 2. Java 4. PHP 5. CSS 5. C++ 5. C# 8. TypeScript 9. Ruby 10. C Img source: https://redmonk.com/sogrady/2021/08/05/language-rankings-6-21/
- 9. How to choose a language? • Adoption in the market, availabilty of devs • Type of application? Back end or Front end • License structure? Open Source • Development community and support (security) • Rest of the application landscape? Maybe limit amount of tech • Migration path from current solution
- 10. Low Code trend • Model Driven Development • Low code • Mendix • 4th Generation • Uniface • No Code • Will they ever live up te expectation?
- 11. Will it live up? • Data modelling, processes, customization, integration Myth 1: You don’t need professional developers • Surely you can do microservices Myth 2: Low-code Apps don’t scale • The actual coding is not on the critical path Myth 3 – Low-code platforms accelerate development speed source: https://www.comakeit.com/blog/common-myths-low-code-platforms/
- 13. Architectural approaches • Monolith • SOA • Micoservices • Event driven • Serverless
- 14. Every pattern keeps coming back • Every architecture choice has it’s trade offs • Central vs Distributed • New & better technology, protocols, design approaches, frameworks and environments cause to
- 18. Comeback of the monolith?
- 19. Comeback of the monolith • Modern development with • Proper CI/CD pipelines • Automated tests • Code review • Security checks • Domain Driven Design • .. • Helps prevent forming messy architecture and code • So only build a distributed system when/where it makes sense!
- 20. Containers
- 21. Cloud adoption • Lot’s of options • AWS • GCP • Azure • Multi cloud (prevent lockin, cost optimization work loads) • Private cloud • Hybrid cloud • Others • >91% use public cloud, 72% private or a combo Credit https://www.forbes.com/sites/louiscolumbus/2016/03/13/roundup-of-cloud-computing-forecasts-and-market-estimates-2016/
- 23. 0 10 20 30 40 50 60 Year 1994 1998 2002 2008 2012 2016 2020 Project succes rate 1994-2020
- 25. Size matters
- 26. Other factors(Standish 2020) • Team, Place and Sponsorship maturity matter!
- 27. Common sense scaling • Ideally you have just one team! • Remember: large projects tend to fail • Platform teams, feature teams, components teams, front end teams, back end teams • Spotify approach: bring domain together • Share a common backlog
- 29. Scaling Agile • Don’t scale! • SaFe • DaD • Spotify • Adding capacity late doesn’t increase delivery speed • Adding additional developers > 7 teams results in diminishing speed gains
- 30. NEXUS
- 31. Post Agile • Scrum doesn’t make sense in DevOps • Proper CI/CD enables methodology • API oriented approach using REST/GraphQL makes dependencies softer • Domain organized teams including business • Docker & Cloud make scaling so much easier
- 33. Platform team
- 34. Layout of a modern team Site Reliabilty egineer QA engineer Security specialist Cloud engineer Front end developer Back end developer Product owner Information Analyst
- 35. Site reliability engineering • "SRE is what happens when you ask a software engineer to design an operations team.” - Ben Treynor Sloss, VP of engineering at Google • Automate the provisioning, monitoring and maintenance of infrastructure • Tightly coupled with (successful) DevOps • SRE wants to meet SLA requirements by using downtime left in SLA as error budget in which improvements can be brought to production. • An SRE • Knows how to code • Understands (cloud) infrastructure • Should spend <50% time doing manual work and >50 automating
- 36. Team practices Living documentation Mob programming Zero Trust Architecture Shift left
- 37. Team Productivity • Four keys • Change lead time • Deployment frequency, • Mean time to restore • Change fail percentage
- 38. Questions
Editor's Notes
- Picture credit https://www.redbubble.com/i/laptop-case/I-Love-Software-Engineering-by-staker/23699211.2U5KG
- http://best-sci-fi-books.com/24-best-artificial-intelligence-science-fiction-books/
- Since I’m running a Java shop it’s easy for me to tell what the best language is! But let’s do a little quiz! What language do you think it the most popular nowadays? Java, C#, PHP, Javascript, Python, Kotlin? Type in your answer and I’ll try to see what you think.
- Redmonk is a UK based independent analyst firm that gives internationally highly regarded data driven reports about software development trends. Every year they publish a ranking of the most popular languages To be included in this analysis, a language must be observable within both GitHub and Stack Overflow. It shows the amount of language discussion and pull requests in the certain period. Not a metric of adoption perse. And I would say certainly not for the Enterprise Software engineering market. Then I would certainly not expect Ruby and Kotlin, Swift and Go should be in there. Kotlin is now 18th, Go 16th and Zwift 11th. Missing 11. Swift 12. R 13. Objective-C 14. Shell 14. Scala 16. Go 17. PowerShell 18. Kotlin
- Also interesting to show is that over the past 10 years the top 4 has been the same, typescript is the newcomer and Ruby and Objective C are loosing ground
- TIOBE is specialized in assessing and tracking the quality of software. We measure the quality of a software system by applying widely accepted software metrics to it. TIOBE checks more than 1056 million lines of software code for its customers each day. TIOBe They have another way of defining what a popular language is. By looking at the job ads. We basically see the same languages here as we saw in the redmonk ranking
- So now that we’ve discussed all that. And tomorrow you’re starting a greenfield project.. What are you going to choose? You can basically build anythin with any language as long as it’s so called turing complete. Bert Jan is currently doing a project at a client of ours called Planon which is market leader globally in Asset managent and the first version of their software was build in Basic, which you might know from the home computers in the 80’s. Anyway, I think the first thing to ask yourself is what characteristics do you need. Performace, scalability, development speed? And where does the code run? At the client on the front end or on the backend using cloud services.
- I guess what’s kind a missing in these programming rankings is the fact that there’s also a trend in the adoption of low code technologies. Surely they been around for many years and known under many different names. With low code the promise is that an enterprise requires no or limited input from devs for years, but they have never been really succesful. Although it has been used a lot.
- https://www.comakeit.com/blog/common-myths-low-code-platforms/ Learning curve to become developer in Low Code less steep But will platforms be around 10 years from now? And capacity in the market While widget and ready to use connectors speed up the process, Java and .Net also have ready to use components And what if the widgets don’t actually offer the integration are performace needed, refactoring can take up a lot of time And don’t forget most low code platform do require you to pay license costs for using the platform. Not the case with Python, Java or Javascript
- Very cool that Dutch based Mendix and Outsystems are doing really well according to Gartner in this space
- Architecture matters. That’s what the dinosaur of Software Architecture Martin Fowler says. Choosing the right architecture can make or break a companies succes. We want our are architeture to enable building software that meets the business goals in an efficient and effective way. But also adaptable and maintainble. There’s a lot of patterns and anti patterns to apply in order to be succesful in this endeavor. First of all let me start by sayingthat there;s not a lot of strong research I’m aware of that gives strong insight in the success and failure of certain architectural approaches. But since I’ve been around in the industry long enough I do think that I know where general consensus in the field lies and where we might be going. In the old days we used to build software that run on a physical server and we tried to code in a clean way by applying for instance proper object oriented principles.Of course also with a separation of the data layers, the business logic and the presentation layer. The three tier approach. But as pressure on projects grew, team members changed and the purpose of the application shifted this applications grew in lines of code and also tended to get like spagehtti code. I guess you’ve all heard about that. These types of applications we’re called monoltihs and often runned core processes and we’re hard to adapt and to maintain. Of course we tried to prevent applications from becoming these monolith where every class and function indirectly or directly depends on another one, but it turned out that discipline wasn’t enough. SOA was an attempt to come up with an architectural pattern to prevent this. If a program wanted to communicate with another application, it was required to communicate with a so called BUS. This bus was the central broker of data and information between connected applications. So one single place were the dependencies between applications and functions we’re managed. While this definitly works, it also was the case in many instances that these SOA’s formatted data for specific clients, resulting in the fact that an application could really change their internal data structure or functions, without also adapting the SOA bus and also the application that got there data from the bus. Basically not solving the spaghetti problem. Around 20xx the Microservice pattern was introduced.
- Picture from https://fabisiakradoslaw.medium.com/microservices-architecture-tutorial-for-beginners-921f19370323
- https://www.manishsanger.com/microservices-an-introduction/
- https://medium.com/unbabel/your-distributed-monoliths-are-secretly-plotting-against-you-4c1b20324a31 But if you’re not carefull, and taking shortcuts, and every server is calling many other services… You still cannot change a single line of code without affecting the rest of the system. You then have a monolith with added network overhead Complexity The biggest disadvantage of microservices lies in their complexity. Splitting an application into independent microservices entails more artifacts to manage. This type of architecture requires careful planning, enormous effort, team resources, and skills. The reasons for high complexity are the following: Increased demand for automation, as every service should be tested and monitored Available tools don’t work with service dependencies Data consistency and transaction management becomes harder as each service has a database
- Every technology, pattern and architectural approach keeps coming back, if you’re long enough in the business. Functional programming is already a nice example, but how about monoliths. Many organization are limited in their ability to repond to change, because they have an application at the heart of their process that has been build out over the years and is not in good shape. It has undergone many quick fixes, lacks automated tests, is working on old version of libraries and components and many people how worked on it with different programming styles. Of course it’s easy to imagine that it’s hard to even maintain these application that are often referred to as monolith are big balls of mud. Understandable how they got formed, and I’m sure you’ve all had to work with them. In many ways the microservices approach was an apporach to deal with this. The idea is that microservices are built as independent functions that do just on thing and are apporachable in a standard way, usually as REST of nowadays a GraphQL API. No network overhead.
- Docker became popular around 2015. It enabled deveopers to package there application in a so called container. This container could be moved to another environment without requiring specific installation instruction and configuration. It was really great and speeded up the DTAP process by a magnitude. Not much later Kuberentes became the defacto cotainermanagement platform. These platform abstract away the opering system and even better, it can automatticaly spin up additional containers running certain services if the load is really high. Running a kuberneter platform of cluster does require specific knowledge and can be easily taken from a cloud service. Docker Kubernetes Changed DTAP
- https://www.forbes.com/sites/louiscolumbus/2016/03/13/roundup-of-cloud-computing-forecasts-and-market-estimates-2016/ 5. 94% of enterprises use the cloud. (Source: Flexera) According to Right Scale’s annual State of the Cloud Report for 2019, 91% of businesses used public cloud and 72% used a private one. Most enterprises actually utilize both options – with 69% of them opting for a hybrid cloud solution. Cloud adoption trends suggest there’s an advantage to using both public and private cloud solutions as this gives more flexibility and a variety of options. Just 22% use the public cloud exclusively, and only 3% use a private one exclusively.
- https://in.pinterest.com/pin/672866000551169449/ It actually matters a lot Data costs vs cost for persistence (saving data). Speed of reading for speed of saving, which regions you want to work globally. (tell Pon anecdote about regions)
- How are we actually doing in software development I colledted all the data from Standish reports from 1994 till 2022 and created the chart you see here. The standish group The 50000 project profiles in the last 5 years Size project zorgt voor meer succes Maturity Agile
- the most recent Standish Group Chaos Study from 2020 shows that Agile Projects are 3X more likely to succeed than Waterfall projects. And Waterfall projects are 2X more likely to fa
- Whatsapp has been made by just a small team of less then 20 people when it was used globally already No matter how you scale, you will loose efficiency and create extra overhead and coordination Trick is to limit shared dependencies between teams, don’t let team A wait for team B
- Who knows what we’re looking at here?
- https://www.scrum.org/resources/scaling-scrum Nex is a whole lot simpler compared to SaFe, which I like a lot already. It focusses on the core issue of why it is hard to build software in multiple teams together. The underlying dependencies. By having an integration team prepare an overall backlog of items that can be picked by different teams in a way that dependencies are clear or avoded upfront it aims to reduce these dependencies.
- Cornerstone of scrum is we don’t accept change during the sprint, and a sprint is a fixed timeframe aka timeboxes. On this basis the team commits to finishing the sprint backlog. This doesn’t make sense if you also apply the mantra if Werner Vogels: “You build it, you run it” which fueled the DevOps movement . Who know which year he said those words? Let me surprise you: in 2006 in an interview. Well if you run it, you need to take care of monitoring and production issues, which mean you cannot commit on finishing a backlog for the next sprint, that would not be fair. Another idea of Scrum is we deliver working software at the end of the sprint. A modern team is of course past that already. Software should be release as soon as it’s ready by applying proper Continuous Delivery practices. If a developer is ready with his story, he should be able to set it live immediately. A few years ago not many organizations were able to do so, now most of our clients are. I do think that this also requires that infrastructure is available for teams and rolled out automatically. If you reach that point, I would claim that you are agile enough. The goal is of course not being agile, but being able to respond to change and develop in a predictable way high quality software that does what the business want. So maybe stop with the agile coaches and scrum masters and focus on perfecting your CI/CD and make sure your could / kubernetes / docker infrastructure. And use what works for your team without adopting a specific framework or methodology Picture http://trinityrfc.com/the-end-of-an-era-kit-sale/
- https://www.visual-paradigm.com/scrum/feature-team-vs-component-team-in-agile/ A component team is an Agile Team whose primary area of concern is focused on a specific component, or set of components, of the system. They leverage their technical skills and interest and focus on building robust components that provide for reliability, separation of concerns, foster re-use, and improve testability. Teams spend much of their time discussing dependencies between teams and testing behavior across components rather than being able to deliver end-user value. A feature Team approach is now almost universally accepted way for organizing their teams, as opposed to the technology stack team, especially, in the continuous delivery approach, it emphasizes features (i.e. a vertical slice of system) that solve user needs which can typically accelerate value delivery of any features or working software and shorten the feedback loop from the real users. A feature team would have all the skills to perform the necessary task-level work to get the job done. In particular, assuming a three-tier architecture, team members would work on tasks related to the GUI, middle-tier, and database parts of this story. As suggested by Craig Larman (the author of LeSS Framework). “a feature team is a long-lived, cross-functional team that completes many end-to-end customer features, one by one.. advantages include increased value throughput, increased learning, simplified planning, reduced waste…”
- SRE works with an error budget SRE is platform team??
- Mob programming (CodeWith Me) Zero t4rust no longer trust the boundary of your network I must reference here the Tech Radar of Thoughtworks, where all kinds of practices and tools are being assessed every your
- Google Cloud’s DevOps Research and Assessment (DORA) team has conducted a seven-year research program. This research has validated a number of technical, process, measurement, and cultural capabilities that drive higher software delivery and organizational performance. https://www.devops-research.com/quickcheck.html change lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage Change lead, how long does it take to go from code committed to code successfully running in production