Technical Debt Patterns: Copied and Pasted Code
This is the sixth part in the series, “Technical Debt Patterns.” There are two (more more!) copies of the same bit of code, because some lazy (or unknowing) programmer copied a whole block and just edited a few lines. Sure, it’s a lot easier than figuring out the right refactoring, and it gets the job done.
Shopping for Quality- How to Ensure You’re Hiring a Company That Can Deliver
I’ve written before that most people who are looking for a software development firm to deliver code for them tend to really care about 3 things. Those things are: 1) Price, 2) Quality and, 3) Speed of delivery. There’s no surprise there – those are the things we all care a lot about in most purchases.
Software on a Budget- Charting the Least Expensive Path to a Successful Delivery
I’ve a friend who’s a software architect for a large (Fortune-100ish) financial institution. If you ask him what his company’s priorities are when working on a software project, it’s simple. The number one priority is security. Scalability is a distant 2nd. Everything else is noise.
Technical Debt Patterns: Overburdened Class
This is the fifth part in the series, “Technical Debt Patterns.” Some important central class has several not-really-related sets of responsibilities, making it huge. Robert C. Martin coined the phrase Single-Responsibility Principle (SRP) as one of his core guidelines in object-oriented design.
Waterfall vs Agile
In Episode 401 of Software Engineering Radio, host Jeff Doolittle spoke with our Senior Software Architect, Jeremy Miller about his experiences with waterfall and agile software methodologies. Jeff and Jeremy spoke about the history of these methodologies, and what elements of them has been either detrimental or useful.
Technical Debt Patterns: Tree Rings
This is the fourth part in the series, “Technical Debt Patterns.” Tree Rings occur whenever you have wrappers around wrappers, sometimes several layers deep. Sometimes this happens because a core of important code is too complex or too fragile for anyone still around to be prepared to edit it.
Key Indicators for High Performing Software Teams
It’s great to hear someone reference a book that you have recently read. It gives an instant level of rapport and usually several good conversation topics. I recently had this experience with tow of our customers as they mentioned an excellent software development book called Accelerate: Building and Scaling High Performing Technology Organizations.
Technical Debt Patterns: Bilingual Required
This is the third part in the series, “Technical Debt Patterns.” This problem refers to the developers speaking a different language about the problem domain than anyone else, including the users. It is a lack of what Eric Evans refers to as “Ubiquitous Language,” the term Eric Evans uses in his book Domain Driven Design.
Technical Debt Patterns: Abstraction Overlooked
This is the second part in the series, “Technical Debt Patterns.” The Abstraction Overlooked pattern is where you have some concrete class that has a “type” of some sort, and you find yourself basing some of its behavior on its type, either through if-then-else or switch statements.
The Fundamentals of Continuous Software Design
Scrum completely dominates the landscape of Agile Software Development these days, but it’s always been a little focused on project management and a little bit light on specific software engineering practices and guidance. It’s unfortunately easy for Scrum projects to drown in technical debt.
