When we speak about orchestration we should think of conductor in philharmonic orchestra. Basically His role is to show rhythm to all musicians. In the other hand “Swan Lake” musical don’t need conductor for dancers. They know when its their part, and which steps they need to do. It’s all because of choreography. Do you want to know more and how its connected to modern software architecture? Check out first local edition of 4Developers in Gańsk and get 15% discount!
When we speak about orchestration we should think of conductor in philharmonic orchestra. Basically His role is to show rhythm to all musicians. In the other hand “Swan Lake” don’t need conductor for dancers. They know when its their part, and which steps they need to do. Its all because… Read more »
Quality Excites (QE) is a Polish nationwide conference on software quality, dedicated to the professionals who use the newest technologies and the best practices. Year by year, the event attracts more and more people who are interested in Quality Assurance (QA) and who want to influence the field. At this conference I will have a pleasure to talk about Evolving Architecture.
During development phase its very easy to cross the design boundary – we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with “overdesign”? How (at the same time) don’t close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very successful. The session for all who don’t want to end up with project that need’s to be rewritten to add a new button. The session for all who cares.
Have you ever considered how your current project architecture will evolve in the future? Have you ever thought how your team will develop certain features for a client? How about possible over-engineering?
In general, we always try to predict all possibilities and changes that the client may require. In the other hand under time pressure developers are being pushed to do different kind of “shortcuts”, which can increase cost of developing new features. How to avoid over-design, but without closing your architecture for all sort of changes that your customer will need in future? When certain technical decisions should be made? When technical debt should be accepted, and when is a need to avoid it?
It will be a story about bad decisions and failures, but also about those decisions that can save the day.
