Software Development

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.

In the grand scheme of things, doing something against the disciplines makes it feel like you're doing it faster but in the real sense, it takes you longer as you deliver poor-quality work that you'd need to improve over time. High-level programmer Robert Martin, AKA uncle bob, suggests that expending more time on your code is actually doing things faster in the world of coding as this leads to clean code. He states that dirty code slows down the development and delivery of tasks and managers should always expect high-quality codes while programmers should dedicate themselves to doing a great job to deliver clean code.

He also adds that a clean code is determined by the size of the methods and the functions. The functions should be simple and small. That way, when you assign names to your tiny functions, corresponding to statements like If or else, the code almost reads like a sentence. It makes it easy to test and detect bugs.

A simple rule that every good, veteran programmer seems to follow with respect to managing their time.

Veteran programmer and blogger Ben Northrop explores the meaning of "Extra" and why most experienced programmers like doing extra work for every little time remaining after the normal work. He details that Extra is doing something useful to your life that is totally separate from your normal work backlog, as it helps us broaden ourselves beyond just what's important on our narrow project. He also notes that Extra has some limitations and there are rules to be followed for success.

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.