The Agile Engineering track focuses on helping developers embrace the agile mindset as it relates to software engineering, with an emphasis on simplicity and architecting for a low cost of change. The goal is to implement fully tested, cleanly designed software solutions that are easily adaptable and architected to maximize business value. This track explores how to inspect and adapt code efficiently and effectively while doing the right level of design at the right time within the development cycle. Cohorts look for ways to write high-quality code that is easily understood, changed, and maintained, while creating a system that is test-driven, or uses a “test-first” approach. They also look for ways to structure work in a more agile manner to respond to customer goals and lower technical risk - enabling a code base that can accommodate new insights, product changes, and technical innovations.
Target Audience
Software Developers, Application Programmers, Systems Designers, Technical Architects, Development Managers, Technical Team Leads, and anyone that either would like to increase their agile programming knowledge or are involved in technical design and development.
Software Development
Software development is a process of writing and maintaining the source code, but in a broader sense, it includes all that is involved between the conception of the desired software through to the final manifestation of the software, sometimes in a planned and structured process. Therefore, software development may include research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.
Related Resources
Show Summaries
A complete interactive website detailing all of the rules (and values) of Extreme Programming (XP)
The turning point in current software development came in the mid 1990s. Many people were re-examining the idea that software must be built like hardware. Jeff Sutherland and Ken Schwaber were formalizing a new process called SCRUM. Alistair Cockburn was working on Crystal Clear. Kent Beck was hired to spend a couple days each month on a project that also hired Ron Jeffries to join notable agile proponents Martin Fowler and Chet Hendrickson on the project. Kent mixed together the best practices from several emerging agile processes with things he had learned while working with Ward Cunningham. It would solve the current integration problem, allow design simplifications, and lead the team to his ultimate goal of collective ownership.
Explaining the metaphor of the interest payments required to clean up the build-up of deficiencies in internal software quality.
Any software system is designed to accomplish a specific task. The more advanced the software system, the better it does its job but also the more complex it is. This complexity creates an internal deficit in the codebase coined as cruft that makes it difficult to modify the system. And becomes a technical debt that gains interest as more features are added. Developers cover this interest as the extra efforts spent on the system. Read this article to learn more about CRUFT and how to stop it from building and resulting in a larger technical debt.
Discussing the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it? Doc discusses the origins of the metaphor, what it means today, and how we properly identify and manage technical debt.
Should we put refactoring "stories" on the backlog?
As "Technical Debt" grows in a project, a question frequently comes up: should we put refactoring "stories" on the backlog, so they are treated as jobs-to-be-done in the next sprint? Should we have an entire session just for refactoring? In this timeless article Jon Jeffries shares his experience as to how to approach refactoring - specially as the codebase grows and starts to slow down the overall velocity of the team.
We usually perceive that it costs more to get higher quality, but software internal quality actually reduces costs.
The trade-off between quality and cost is that it costs more to deliver a quality product or service. However, this is not the case when it comes to software development. The quality of software lies in its internal code architecture than the external features. The better the internal code is divided and structured in modules, the easier it is to modify and fix for a programmer. But poorly structured software contains some degree of complexity called cruft that makes it costly to add more features and fix. Learn what software quality means, its importance, and its impacts on developers, users, and customers in this article.
Analyzing the Software Craftsmanship Movement - its origins, benefits, and why it is still not working.
The article analyzes the Software Craftsmanship Movement - its origins, benefits, and why it is still not working. It details that the Agile movement failed to promote the original idea of programmers that was based on work perfection, value addition, and following the disciplines of craftsmanship but rather promoted conferences and certified Scrum Masters and project managers.
Setting the expectations of who gets to make what calls on software projects.
When XP (the pre-cursor of Agile) came out, it attempted to make clear who gets to make what calls on software projects. For example, business has the right to know how long something is going to take and when it can expect things to be done. Conversely, developers have the right to know what the priorities are, and to be able to do good work. The XP Bill of Rights was born to further clarify the rights of Customers and Developers.
Learn what it is, its difference to other types of software, and why do people prefer using open source software.
Introduction to pair programming, its roles, mechanism, and challenges.
How an engineering manager can stay true to the clean code principles, and lead a team that builds quality software.
A simple rule that every good, veteran programmer seems to follow with respect to managing their time.
A Requirement for Good Engineering
In a classic publication, Paul Gill and William Vaughan share experiences with initiatives associated with NASA's technical excellence thrust - a division designed to maintain high levels of performance in the organization. A timeless article looking at the elements of good engineering.
Software Architecture
Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.
Related Resources
Get a high-level understanding of an approach to software development based on making your software deeply reflect a real-world system or process.
Get a high-level understanding of the Domain-Driven Design approach of software development that allows developers to create expressive, easy to test, and layered applications based on real-world systems or processes. The article guides us through what is a domain-driven design approach, its basics, and how to manage the life cycle of domain objects.
Ignoring tech debt is the right way of building a product no developer wants to work with.
Logic
Logic comes from the greek word "logik?", which means "possessed of reason, intellectual, dialectical, argumentative". It is the systematic study of valid rules of inference, i.e. the relations that lead to the acceptance of one proposition (the conclusion) on the basis of a set of other propositions (premises). Logic includes the classification of arguments; the systematic exposition of the logical forms; the validity and soundness of deductive reasoning; the strength of inductive reasoning; the study of formal proofs and inference (including paradoxes and fallacies); and the study of syntax and semantics.
Related Resources
Grasp the underlying patterns behind each question and use them as a template to solve a myriad of other problems with slight variations.
Reasoning
Reasoning is associated with the acts of thinking and cognition, and involves using one's intellect. Like habit or intuition, is one of the ways by which thinking moves from one idea to a related idea, or to produce logically valid arguments. Reasoning is the means by which rational individuals understand sensory information from their environments, and conceptualize abstract dichotomies such as cause and effect, truth and falsehood, or ideas regarding notions of good or evil.
Problem Solving
The act of defining a problem and determining its cause; identifying, prioritizing, and selecting alternative courses of action; and implementing a solution.
Artificial Intelligence
Artificial Intelligence is said to exist in any device that perceives its environment and takes actions that maximize its chance of successfully achieving its goals. The term is often used to describe machines (or computers) that mimic "cognitive" functions that humans associate with the human mind, such as "learning" and "problem solving". As machines become increasingly capable, tasks considered to require "intelligence" are often removed from the definition of AI. The traditional problems (or goals) of AI research include reasoning, knowledge representation, planning, learning, natural language processing, perception and the ability to move and manipulate objects.
