Can you “foresee the feature?” Do you know if proposed changes to your application will have the desired impact to your business? Let’s drop the crystal ball approach and start practicing some hypothesis-driven development so you can test your assumptions. Not every new feature is guaranteed to be a success. Some might just waste time and increase your technical debt. Join us for the next online DevNation Live on July 5th at 12pm EDT for Feature Toggles and Hypothesis-driven Development, presented by Red Hat director of Developer Experience, Edson Yanaga.
In this session, we’ll demonstrate how feature toggles can be incorporated into your software development process to let you quickly assess the business results of changes. By toggling functionality on and off, you can measure the impact and make better decisions based on real data.
Join us to gain an understanding of how the use of hypotheses, not requirements, can help you deliver what your business actually requires while learning quickly what works and what does not.
Register now and join the live presentation at 12pm EDT, Thursday, July 5th.
Continue reading “Next DevNation Live: Feature toggles and hypothesis-driven development, July 5th, 12pm EDT”
The idea that once our code is working, we are good to go is a very bad idea. An idea that needs to be reevaluated and analyzed. When you buy a car, it works at first, and then it begins to develop faults. Do you have to wait for the car to develop faults before you begin maintaining it? Well, the answer is obvious and the answer is NO.
But why then do we have to do the same thing to our code. Once a piece of code works or passes that test, we close that code and never ever look back. Even the car at Toyota passed the test before it was delivered to the client, but it also has to be maintained. Some people would argue that code maintenance is far more different from maintaining a car, but I would beg to differ. What is maintained in whatever form is better than what is never maintained?
Continue reading “Code Maintenance”
During Red Hat Summit, I was part of what we called Birds of a Feather session; this is the type of session where you place a bunch of people in a room to talk about a topic with no agenda or solidified content. The topic for the session was “Agile Software Development – the Red Hat Way.” The panel consisted of engineers, product managers, customer support reps and program managers who work on our product line using the agile methodology. The focus was to have an open conversation about how we work at Red Hat.
Continue reading “Agile Software Development – The Red Hat Way”