Articles

Technical Debt Affects Everyone

,

If you’ve read our piece about the habits engineers need to beat tech debt, you might recall Conway’s law, which states that organizations which design systems […] are constrained to produce designs that are copies of the communication structures of these organizations.

It’s one of the forces that can push us towards technical bankruptcy because the systems designed by software engineers are constrained by their company’s organizational structure, over which they have little control. The right way to fight these forces is to talk about tech debt across the whole company so that everyone can understand why it’s vital to manage it carefully.

Source de l’article sur DZONE

/par

Code Transformations

,

A lot of poor designs can be attributed to sticking with an existing design as changing requirements show us the need for a better one. Oftentimes, an initial design is just a stab in the dark. We might not know enough to make an informed decision but we have to get something done, so we do what Agile says and we code up the behavior that we need right now and not worry about future requirements.

For most teams, the problem comes when they start to enhance that behavior and go back into the code to extend it. Now they’re asking the system to do something that it couldn’t do before and, instead of redesigning a feature to accommodate the new behavior, developers might try to hack in the new behavior while minimally impacting the existing design. But this can degrade the quality of the code when done over and over again in a system.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

TDD Example in Software Development (Part 2)

,

Let’s continue with our series of TDD articles. In the first part, we looked at the theory behind TDD and Unit Testing. In this second part, we begin to develop our application, an application of notes where a user can write notes and everything that comes to our mind. Please, leave comments if you are interested in seeing how we develop any specific functionality in our application.

TDD First Cycle

To start developing our application, we could start with the user entity (quite generic and it is used for everything). We will see later if it is necessary to change it to something more concrete.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

4 Things I Include in My Agile Estimations

,


Estimation is one of the most difficult aspects of the Agile process. The natural tendency of team members is to include only the time it will take to complete the actual work for the item they are estimating. I have a process where I break each work item down into 4 parts to help me get a more accurate estimate. This is a process I use all the time in my current role as CTO of CUE Marketplace and I hope it helps you in your Agile estimations.

Understanding the Big Picture Estimate

I want to know every aspect of the work item that I’ll be completing, so I add any time it would take for me to fully understand it. It’s a huge time saver if my Product Owner has written the work items as user stories. That format helps with the “who,” “what,” and “why.” Other items that could take time include understanding any UI designs/clickable demos, reviewing usability tests and getting to know the “who” part of the story by researching the customer or persona.

Source de l’article sur DZone (Agile)

/0 Commentaires/par

Surgery on Legacy Code

, ,

One of my early blog posts that I wrote nearly 10 years ago that I called "Sony Baloney" discussed how the electronics giant cultivated some unusual, yet highly successful practices. One of the practices that Sony is known for is taking young and inexperienced engineers and putting them on new product development, while their senior engineers focus on reworking and redesigning their successful products to be more cost-effective. I consider this to be a very wise practice and so do they.

We want innovation in new products but we always want to balance it so that our work is maintainable and cost-effective. The electronics industry pays a lot of attention to this because manufacturing is expensive. Of course, there are no manufacturing costs, per se, in the software industry but there are maintenance and ongoing costs for software and that’s actually where the bulk of our funds are spent. So, paying attention to the maintainability of our code is quite important yet often overlooked.

Source de l’article sur DZONE

/0 Commentaires/par