This blog post is all about ... designing nuclear power-plants, insatiable desire to put CQRS, eventsourcing & microservices in every software product, engineers' maturity, what's more important: problems or solutions & how JIRA can help (yikes!).There are some terms in IT you'll probably never learn at any CS University course. Yet, they are too important to omit & one of them is "bike-shedding". Frankly, I haven't heard this particular term until last year's outstanding presentation by Jimmy Bogard.But let's assume that for whatever reason you haven't so far & don't want to watch Jimmy's vid. Basically ...Bike-shedding happens when…
All posts in “Software Engineering”
TL;DR In majority of scenarios real technical mastery has a tertiary degree of importance - being just solid, playing it safe & avoiding accidental complexity is just enough until market gets very dense, interest reaches viral levels or competitive factor is about pure tech (very rare). Very few companies (excluding some unicorns) compete with just tech as their primary weapon - it's usually all about the product, idea behind it & how fast it has been delivered (before the competitors ...). Disclaimer: keep your seatbelt buckled up, we're going to get a bit controversial here & you may not like…
TL;DR Building software while "on auto-pilot" doesn't work well - operational automation is more than advised, but understanding (in-depth) why-you-do what-you-do is absolutely essential. However, there are certain practices many stick to, without really understanding their purpose & descendant effects. One of them is "staging" - an anti-pattern that should in general be avoided, but when applied properly, can temporarily reduce the risks & help in transformation towards more mature delivery model. However, too many thoughtlessly treat it as a permanent element of their delivery pipeline, w/o thinking about its consequences & accompanying "…
TL;DR The entry threshold in software development industry gets lower & lower - it's a great opportunity for so-called developing countries to spur the "close-the-gap" efforts towards more advanced ones. Some approach it more naively (ehhh, India ...), some approach it smarter - I had a chance to take a peek into how it's done in Tunisia, perceived as the most open & progressive Arabic country. My general impression is that Tunisian software developers have strong enough foundation to be competitive / cooperate as equal (depends on whether you see them as competition or associates) with their European / American…
TL;DR Knowledge is power - you can't foresee & script creative way of knowledge workers if you really expect valuable outcomes. The only way is (once you get proper people first) to provide them necessary degree of freedom & contextual knowledge - up-to-date, comprehensible, applicable, broad yet adjusted to the goal - in short words: the proper CONTEXT. My geeking around sometimes sends me drifting towards rather surprising waters ... for instance: behavioral / congitive psychology. "Thinking fast & slow", flow, psychology of change, etc. Some of the most interesting research materials I've got myself through were about ... jet…
TL;DR Too many problems in modern software solutions development are related to chasm between 'thinkers' (analysts, people with business knowledge) & 'doers' (IT specialists, mainly programmers), yet we're so used to it we treat it as something carved in stone. Why not try to apply the same bridging concept that was foundational for coining the term 'DevOps' to mix these two worlds - software crafters with sufficient understanding (& working ability of) domain analysis & technical implementation sounds almost like a mythical silver-bullet. Barely anything in life is either black or white, we're usually navigating across various shades of…
TL;DR If maintainability & extensibility of your software are among the top priorities, readibility & easy-to-grasp correspondence to functional requirements are far more important than conciseness & technical "aesthetics" (e.g. compliance with patterns) of your code. That's why to build good solutions we need much more expressive power than what any of the programming languages (of the day) offers. At some point we believed NLP will solve this issue & we'll get there with Nth GLs. This is not the case. Instead of building more generic programming languages, we need to get better with building custom…
TL;DR The older I get, the less patience I have - that applies to people as well, but (fortunately) I keep it healthy -> what irritates me is not someone's lack of knowledge or mistakes made, but rather immature or non-constructive follow-up. What is really important is not really the fact that an error has been made (ofc, it's nice to minimize the consequences), but to apply proper learning & knowledge inference process. One of the best things about working in software development is meeting so many smart, interesting people with incredible variety of past experiences & unique…