Poor developer + AI = Poor results (still)
May 2026
WSZiB From Student To Pro [pl]
Apr 2025
WSZiB-30-lecie Link do mojej prezentacji z konferencji “From student to Pro”
https://fromstudenttopro.wszib.edu.pl z 04.2025 dla absolwentów kierunków Informatyka i Informatyka Stosowana WSZiB w związku z jubileuszem 30-lecia istnienia uczelni.
Devoxx Poland 2016 Scale JEE up into containers…
Aug 2016
My presentation from Devox Poland 2016 regarding our experiences, successes, and failures while transitioning a legacy Java Enterprise Edition (JEE) stack into a highly scalable, containerized infrastructure
https://www.youtube.com/watch?v=NzCg2Sb-GRc
To scale up to thousands of instances while remaining vendor-agnostic and cost-effective, they built a custom hybrid architecture utilizing the following stack
- Docker: Used as the base infrastructure to isolate applications into stateless, immutable container units
- etcd: Acting as a global, fault-tolerant key-value registry to track live containers, port numbers, and client metadata across different regions
- Confd & Nginx: Confd dynamically listens to changes in etcd to seamlessly rebuild and reload Nginx proxy configurations whenever a Docker container moves or restarts
- Ansible: Leveraged to easily decompose build parameters, customize baseline images through Dockerfile processing, and automate the provisioning of newly purchased bare-metal boxes [
- DataDog & DNS Simple: Integrated DataDog for affordable multi-host container monitoring and DNS Simple for zero-TTL, automated domain routing to allow seamless traffic migration between data centersConclusion
By building their own container orchestration layer on top of commodity hardware pairs (using master-slave database replication) , XTRF managed to drop their infrastructure cost below their original bare-metal overhead . They successfully bypassed the architectural restrictions of their legacy code while simultaneously improving high availability, scalability, and deployment times
Requirements change during a sprint?
May 2013
As we all live in a rapidly changing environment we have to face requirements change from time to time. It’s not such a big deal unless it pertains to user stories that have already been put into sprint backlog.
So why is a change within a sprint a bad thing?
Firstly It does clearly indicate that what was planned and agreed just few days ago is not valid anymore. Long hours spent on planning turns out to be just a waste of time an energy. http://www.infoq.com/news/2008/12/change-requests-in-scrum
Secondly, what is left from a commitment made during the planning session might be more difficult to achieve or even not achievable at all. Team morale will go down as no one likes people that do not keep promises. Does he?
Finally, if someone affects commitment he instantly takes responsibility for an outcome. Team members tend to have a proclivity towards switching to “I don’t care” mode as it is not “my promise any more”. This leads directly to unreliable commitment and unsustainable delivery process.
So what can we do about it?
The answer is pretty simple. Predict what is unpredictable.
Say what?
If there are recurring tasks like 3rd line support or resolving production issues it should be possible to estimate how much time and resources those may take. People are already experienced enough to know what may happen. Let them drive this demand and take responsibility for it.
Hold on! Scrum is all about being eager to react to changes rather than planning everything upfront. http://agilemanifesto.org/The company is not for employees benefit but for meeting customer needs.
That’s True. However, change responsiveness comes from adjusting sprint length, frequency of deliveries http://martinfowler.com/bliki/FrequencyReducesDifficulty.html and managing backlog properly. We are a professional company and we know what we will be doing in 2 weeks. Right?
It should be a natural reaction of scrum master to keep terms and condition of a “contract signed between a team and a PO unchanged for a duration of a sprint. Team should push back on changes to requirements to stay focused on a commitment.
What if an user story being implemented turns out to be useless unless requirements are changed?
It would probably make more sense to descope the user story and let it flow through planning process again rather than to hot swap requirements hoping that no one will notice.
So what shall we do if more user stories from sprint backing need an urgent requirements review?
Off course there are rare situations when requirements change drastically making sprint goals useless from business point of view. The only reasonable action is to cancel a current sprint and start planning from scratch. However that would indicate that something went terribly wrong in first run.
