Portrait

Aleš Křesťan

SW Developer, Solution Architect,SDLC Consultant, Team Leader,DevOps Engineer

Core Services

  • Java SW development, solution refactoring, and maintenance
  • Architecture reengineering, modernization for microservices and cloud
  • Technical and organizational debt reduction
  • SDLC optimization for sustainable agile development
  • React & Next.js applications maintenance
Professional BioLinkedIn

Hindrances of sustainable agile development

Preface

Out of hope for better-functioning workplaces

01

In keeping with my introductory post on LinkedIn here, I welcome you to this specialized miniblog. The posts are based on my direct personal experiences, collected from my participation in 10+ projects, some engagements being longer, some shorter.

Yet, in hindsight, they all appear to manifest the same set of reoccurring problems; each project having its own specific dose of the discussed symptoms. Those projects' shortcomings are attributable to various things such as the lack of understanding of the Agile Manifesto's principles, lack of experience in leading the team, lack of interest in the later phases, and also neglect. If I were to choose one that sticks out: Agile Manifesto's principles are not read as lessons learned by others that are to be re-interpreted and re-implemented in full in the context of the SW solution that is being built. The most visibly missing ingredient is sustainability.

Despite being rooted in concrete environments the blog posts are written abstractly and are mostly centered on 3 main archetypes participating in the SW development process: the organization representative a.k.a. the boss, the development lead, and the developer.

Focusing on this last role, I hope the leaders — those managing SW development and operations — will, after reading the blog, think more about how they hire. Recruitment for SW development positions shouldn't be just about checking a candidate’s proficiency in a specific tech stack. If for nothing else then because the tech stack may become obsolete by the time the project starts preparing a "version 3" - "version X" being a figure of speech in an environment where we should strive for the work flow to be continuous. Along with giving some thought to the things like how they would want the day-to-day business to be run, what the communications in the team should look like, what's the cost of any kind of change (including bringing a new team member up to speed) after an MVP has been delivered and the first success celebrated.

The bottom line: SW developers are not the same kind of people as programmers. I have met great programmers (far better than me), decent programmers and poor programmers; I have also met good SW developers and bad ones. I have met a solid programmer who made a sub-par SW developer. However, I have yet to encounter a respectable SW developer who was a bad programmer. I encourage you to do your own research on the subject.