Infrastructure code in Agile software development

•Download as PPT, PDF•

4 likes•1,648 views

Infrastructure code refers to software layers with APIs that are used by multiple users and teams for different purposes. It supports principles like DRY and helps manage shared resources. Traditionally, infrastructure code is never truly complete, becomes too large to manage effectively, and creates bottlenecks. However, taking an agile approach by having multiple feature teams own infrastructure and developing it iteratively reduces bottlenecks and risk while increasing flexibility and business understanding within teams. This requires effort to implement cross-team communication but yields business benefits.

Technology Business

Infrastructure code in agile software development Elad Sofer – Agile coach blog.thescrumster.com [email_address] Twitter: @ eladsof

What is infrastructure code? ,[object Object]

Infrastructure code is Good! ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Software infrastructure The traditional way - Common problems

#8 – Component Teams Component A Component B Component C Infrastructure

#8 – Component Teams Release feature list: Feature 1 – A(20%) B(30%) I(50%) Feature 2 – A(40%) B(20%) I(40%) Feature 3 – B(50%) C(10%), I(40%) Feature 4 – A(40%) C(10%), I(50%) Feature 5 – A(20%) C(50%) I(30%) Total Effort needed: A – 120 B – 100 C – 70 D – 210 Component A Component B Component C Infrastructure

#8 – Component Teams ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Agile s/w development ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Feature areas UI Business logic Data model Infrastructure Security related Features User admin related features Item CRUD related features Reporting related features

Feature teams ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Balance discipline and flexibility. ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]

Technical debt is a metaphor for the gap between the current state of a software system and its hypothesized ‘ideal’ state. One of the significant and under-investigated elements of technical debt is documentation debt, which may occur when code is created without supporting internal documentation, such as code comments. Studies have shown that outdated or lacking documentation is a considerable contributor to increased costs of software systems maintenance. The importance of comments is often overlooked by software developers, resulting in a notably slower growth rate of comments compared to the growth rate of code in software projects. This research aims to explore and better understand developers’ reluctance to document code, and accordingly to propose efficient ways of using persuasive technology to encourage programmers to document their code. The results may assist software practitioners and project managers to control and reduce documentation debt.

The Evolution of Software for a Startup

SARCCOM

The five expertise of a software architect

Lior Bar-On

The document discusses the five areas of expertise of a software architect: 1. Technology - Having strong technical skills including writing code, understanding technologies, and solving difficult problems. 2. Technical communication - Effectively communicating technical concepts to both technical and non-technical audiences. 3. Human communication - Having strong empathy, influencing, and communication skills to work with various teams. 4. Domain knowledge - Understanding the business domain including customers, competitors, and market factors. 5. Architectural methods - Applying design principles, patterns, and processes to software architecture.

Dev Learn Handout - Session 604

Chad Udell

The document discusses how to build a reusable eLearning framework using APIs. It notes that APIs can provide significant cost and time savings through standardization, shorter development cycles, improved quality, and better risk management. When creating an API, planning and collaboration are important. The API should have intuitive methods and properties to allow code to ignore implementation details. The first steps are to identify commonly repeated tasks and code from existing projects to determine what to include in the API.

How can agile help you in clearing the technical debt

Manu Pk

The document discusses how Agile practices can help teams pay off technical debt. It defines technical debt as poor software development practices that increase the cost of future changes. It recommends continuously integrating code, using quality tools, and negotiating with product owners to prioritize technical debt repayment. The document suggests using spikes to experiment with new technologies and evolving designs over upfront designs. The key message is that Agile teams can detect and address technical issues using practices like continuous integration, code quality tools, spikes for experimentation, and negotiating priority of technical debt repayment with product owners.

Mobile engineering at GOJEK Scale

raditya gumay

The document discusses mobile engineering at scale at Go-jek. It outlines Go-jek's mobile app milestones from 2010 to 2018. It then discusses challenges of engineering at scale, including that having many engineers does not necessarily mean faster feature delivery. It recommends centralizing engineers and sharing code between features to address these challenges. It also discusses problems like semantic versioning, slow builds, and onboarding. It provides solutions like monorepos and clean architecture to address these problems. It emphasizes the importance of testing, team collaboration, and referencing best practices.

Architecting for Hyper Growth and Great Engineering Culture

ifnu bima

The document discusses architecting for hyper growth and great engineering culture at a software company. It summarizes: 1) The goals are to support hyper growth year over year while fostering innovation and fast iteration through software architecture choices. 2) As a software architect, responsibilities include designing architectures around choices like monoliths vs microservices and databases, picking platforms and libraries, and setting hiring standards. 3) Architectural priorities are speed, performance, scalability, security and code quality to support the goals and customer experiences.

Using Spring Boot Effectively in Cloud Foundry

Josh Ghiloni

This document discusses Spring Boot and compares it to traditional Spring frameworks. It notes that Spring Boot is opinionated and aims to accelerate time to market by significantly reducing the amount of boilerplate code needed. The document shows an example of the boilerplate code required for traditional Spring configuration versus the single class needed for basic Spring Boot configuration. It also provides metrics on the lines of code, WAR size, and app start time for a sample app built with both traditional Spring and Spring Boot, demonstrating the reduced complexity of Spring Boot.

Rahul Vats worked as a Software Development Engineer at Global-ID Group for 5 years from July 2008 to June 2013. His responsibilities included maintaining an existing .Net database web application used by 500 clients, overhauling several Kentico CMS websites, assisting with webapp builds, QA, and releases averaging twice a month, and working on software development projects involving bug fixes and new features using C# and related technologies. Rahul got along well with coworkers, was available after hours as needed, and collaborated effectively with coordinators on requested features. His manager, Mark Cutter, provides a positive recommendation.

DevOps & Technical Agility: From Theory to Practice

Lemi Orhan Ergin

Sra1(swt) ppt2

Sravan Kumar

Software refers to the programs and operating information used by computers. Software developers, also known as software engineers, are professionals trained to apply engineering principles to create, implement, test and maintain software applications. There are two main types of developers: frontend developers who work on the user-facing components and backend developers who work on the server-side components like databases. Frontend technologies include HTML, CSS, JavaScript and jQuery which are used to build the interactive parts of applications. Backend technologies include databases like SQL Server, Oracle and MySQL which store and manage application data on the server side.

Aspect oriented architecture

tigneb

Aspect Oriented Architecture (AOA) is an effective agile development method that involves breaking down functional components into parts of the software architecture. AOA tools like AspectJ, join points, advice, and pointcuts are used to address cross-cutting concerns. AOA was applied to the Capella online learning system case study to increase workflow processes and provide a positive customer experience. While AOA allows for effective review of programming mechanisms and better understanding of cross-cutting concerns, potential disadvantages include modifications due to inconsistent tools, performance issues with some applications, and limited reuse of aspects.

Getting Started With QA Automation

Giovanni Scerra ☃

The document discusses QA automation, including challenges like ensuring tests are resilient, simple, and comprehensive. It also discusses solutions like developing an automation framework to write high-level tests and using infrastructure for speed and parallelization. The document recommends considering outsourcing automation by evaluating factors like criticality, expertise needs, and test integration.

20080531 Intro To Dependency Injection & Inversion Of Control

donnfelker

Donn Felker will present on dependency injection and inversion of control. He has 8 years of experience developing enterprise solutions and various technical certifications. He will define dependencies and dependency injection, discuss the pros and cons of dependency injection, and demonstrate examples of dependency injection and inversion of control using a custom dependency container and the Microsoft Unity container. Resources from the presentation will be made available on his blog.

Some Myths in Software Development

bryanbibat

.NET Career Direction

Volodymyr Voytyshyn

Onion Architecture

matthidinger

The document discusses the Onion Architecture, an architectural pattern that aims to put business logic at the core of applications and reduce dependencies between layers. It describes problems with traditional 3-layer architectures where business logic can become scattered and dependent on specific technologies. The Onion Architecture inverts dependencies so that inner layers do not depend on outer layers, making the business logic portable and easier to maintain over time. Guiding principles are to use dependency inversion and push technology dependencies outward from the core business logic.

Post-REST Manifesto

Jakub Nesetril

Harmony in API Design

Jakub Nesetril

The document discusses key principles for designing APIs, including that an API serves as an interface between systems and cultures. It emphasizes involving customers early in the design process, starting with a wireframe, and maintaining exhaustive and up-to-date documentation that is automatically generated and tested. The document concludes that APIs should have their contract separated from implementation and encourages automating the design process.

Blue Prism Top Interview Questions | Edureka

Edureka!

YouTube Link: https://youtu.be/ykbRdUNIbyQ ** RPA Training: https://www.edureka.co/robotic-process-automation-certification-courses** This PPT on Blue Prism Interview Questions will cover the Top 50 Blue Prism related questions asked in your interviews. Follow us to never miss an update in the future. YouTube: https://www.youtube.com/user/edurekaIN Instagram: https://www.instagram.com/edureka_learning/ Facebook: https://www.facebook.com/edurekaIN/ Twitter: https://twitter.com/edurekain LinkedIn: https://www.linkedin.com/company/edureka Castbox: https://castbox.fm/networks/505?country=in

Rebooting APIs at scale

Rahul Dighe

PayPal operates in 200+ countries. The complexity of region specific requirements and a disjointed offering led to a situation where PayPal Checkout API product suite got polluted with many overlapping capabilities and an API documentation that was hard to comprehend, incomplete and inconsistent making the integration experience much harder than it needed to be. There was a strong desire to act upon the feedback that we have been hearing from our merchants and developer community to make a turn for the better. This talk aims to explore > When is the right time for organization to rethink their API and launch a new version. > Considerations that go into creating a new version of an API that is so central to the way thousands of developers and merchants integrate with PayPal. > Explore challenges in design, adoption, migration both internally and externally within the organization.

1. Introduction

Ashis Kumar Chanda

The document discusses the goals and challenges of software engineering. It notes that the goals of producing software that is correct, with minimal effort and cost, and in the least time are difficult to fully achieve. Large software involves many people and millions of dollars over many years. Real-life examples like Eclipse have over 1.35 million lines of code and cost over $54 million to develop. The document outlines why software engineering is important to avoid costly failures and ensure efficient development. It also discusses myths and the need for different approaches like formal processes for large software.

Introduction to Aspect Oriented Programming

Yan Cui

The document discusses cross-cutting concerns in software development that are difficult to separate using traditional object-oriented programming techniques. It introduces aspect-oriented programming (AOP) as a solution to modularize cross-cutting concerns by allowing code to be separated into distinct parts (aspects) and joined together at certain points (join points). Finally, it describes different ways that AOP can be implemented, including through dependency injection frameworks, functional programming, code generation, dynamic languages, and static weaving tools like PostSharp.

Scrum Events and Artifacts in Action

Lemi Orhan Ergin

How To Become An Excellent Software Engineer, by Lee Bob Black

SkilledUp

This document provides 7 steps to enhance one's software engineering career: 1) Enroll in a coding bootcamp to take coding skills to the next level. 2) Consider mastering more than one programming language. 3) Join code repositories like GitHub to contribute to open source projects. 4) Learn code refactoring skills. 5) Create an online portfolio to showcase work. 6) Attend software engineering conferences. 7) Improve non-technical "soft" skills like problem-solving, time management, and communication.

Idol software presentation

darleneputnam

This document defines and provides examples of application software and system software. Application software enables users to perform specific tasks, such as using Microsoft Office programs, project management software, and accounting programs. System software includes operating systems, utility programs, and language translators that control computer operations by starting the computer, processing applications, and controlling devices. Emerging technologies may change the future of computer software.

Мобильная разработка. Между Сциллой и Харибдой. Native, hybrid or cross platf...

Artjoker

This document discusses different approaches for developing mobile apps: native, hybrid, and cross-platform frameworks. Native apps are written for each platform separately using platform-specific tools. Hybrid apps are wrapped in native code to access device features. Cross-platform frameworks allow writing common code that compiles or interprets to each platform. React Native uses JavaScript interpreted to native code, while Xamarin compiles C# to native apps. The document compares factors like maintainability, performance, cost across these approaches to determine the most effective way to reach broad audiences.

Test Automation - Insights Into Frameworks by Anup Patnaik, QA InfoTech

QA InfoTech

Tools and techniques for automated test execution have been around even before the activity of testing was seen as independent of debugging. And with growing complexity of software, companies have embraced test automation as an integral part of their test strategy. This is primarily to augment human testing in order to meet goals ranging from increasing test coverage on greater number of platforms to shorter release cycles. However, it is surprising to see how many of these projects fail. According to some industry estimates, 85% of these projects fail to bring any real ROI. Along with answering the all important questions of what to automate and when to automate, test managers need to understand the implications of using the various tools, techniques and frameworks. And this choice is largely determined by the mission that the project needs to accomplish. Will only the underlying tool suffice, what would be the limitations? Should you be using a keyword driven framework or should you be designing a domain specific language on top of your tools? Given a fast changing application, which of the many approaches will work better? Which one can be learnt and adopted faster by a large team of human testers? These and many other questions can be answered only by the experience of applying the approaches to real projects. In this talk, based on our long experience of working on test automation projects, we help test managers understand and answer similar questions. We trace maturity of automated testing from tools to frameworks, and detail out the nuances and pit-falls of the approaches in the wake of a given mission. In addition we show how using the many open source tools test mangers can develop robust yet cost-effective solutions.

SE_conf2 Tomer and Ram final

Tomer Peretz

The document discusses two approaches to system engineering and software architecture integration: the glue approach and the connector approach. Under the glue approach, software is seen as the "glue" that connects together hardware parts, resulting in software delays and difficulties reusing code. The connector approach involves software architects earlier in system design, shaping both hardware and software together as connectors. This allows for more flexibility, reuse, and addressing quality requirements throughout the system development process. The presentation argues the connector approach better fits Orbotech's environment and is their preferred method going forward.

Domain specific languages

Dror Helper