Somewhere in London, usually
Software development myths
If someone tells you that making good software is easy, or that everybody could do it, or makes it look like it is easy, it is likely a salesman speaking.
Aiming at good, and I mean really good is actually very hard.
Making it right is not more expensive than making it wrong, provided you take the right decisions early on.
in software, tiny details matter, and they are not necessarily the details you see, the shiny graphics and presentations that matter.
Self proclaimed experts are a dime a dozen.
"Agile" means very little by itself.
Actually, Agile does not mean that you should blindly follow the methodology and expect it to work.
Agile needs to be customised to the organisation and is not a panacea.
It is not a cure all approach, and as all methodologies, or tools, is best handled when critical thinking and an open culture is in place.
For instance, if you have a limited budget and timescale, you can't be completely "Agile", you will however benefit from having Agile ceremonies.
Agile alone is not enough, as a strictly non-technical scrum process can determine crippling technical debt. You can't be agile and just ignore the technical management of a project.
Methodologies don't really matter, or, to be more precise, they matter a lot less than the experience and competence of the developers involved in a project:Michele Fadda
A competent developer would probably manage to reach successful project completion no matter what the software development process is.
An incompetent agile developer, would not reach a successful outcome, no matter what methodology is in place.
Sharing knowledge and growing together.
I've been around developing software for about three decades, in so many different organisations that I've practically become a sort of corporate anthropologist.
Good teams are more than the sum of their individual parts. Bad teams are just the opposite: politics, personal agendas and egos drive to inferior achievement.Michele Fadda
The least creative teams are those characterised by strong cohesion and conformity: if all contributors are all alike, come from the same culture, have the same age, you can expect stagnation.
If it’s too technical for you
Rather than refusing a technical topic entirely, try to become a little more involved with technology.
There's always some task which is more difficult for us than what we are used to do better and more naturally.
It might be math, or talking to an audience in public.
However, pushing our boundaries and learning new skills is the only way to capture opportunities we would have otherwise missed, being more aware of our environment.
Next time, try not to say the words "It's too technical for me". You might discover that it really isn't as hard as you imagined.
Remember when they were telling that companies should not get involved in "non core" activities, because they did not matter strategically?
How do you explain the fact that nowadays Amazon, a librarian, dominates cloud platform market? Maybe IT is a strategic core activity for every world class organisation, after all, and the right details do matter.
You should always take broad generalisations and management fads with a grain of salt.
Chiefs tend to be opinionated about their tools
A good chief typically uses many different knives, and be quite passionate about their different uses. Good software development is not different, and is more akin to craftsmanship and art than actual engineering.
The right tools do make a difference Thus not all programming languages are the same
Some programming languages are more expressive, or are more suited than others for a particular task. Some are very fast, but it isn't at all easy writing safe code with them.
Some programming languages have implementations which might be less secure and leave your system more amenable to attack or reverse engineering. Or their license might not be as free as you think, leaving you exposed to higher costs in the long run.
You should base the technology choices on the problem at hand, and on your organisational environment, not on preconceived prejudices.
You probably shouldn't be using Java in a startup, because cheaper, more effective alternatives exist within that organisational environment.
Choosing the appropriate tools for a task is a strategic decision: it will affect you and your organisation for many years to come, and each tiny advantage a software tool could offer you (or remove from the table) will add up in the long term.
If all you know is python Django, and use it because "authentication in Django" is really easy, probably the system you are going to design is not going to be super-secure, if an additional level of security is required, e.g.: storing confidential sensitive information about your users.
The very worst decision is using just what you know, and never look at alternatives because of your own personal history.
Another terrible decision is going with the flock, following a fashion, just because everyone else is doing the same thing.
By definition, if you do precisely what everyone else is doing, you are removing any chances at getting any strategic advantage from your implementation.
However, no matter what you choose, it has to be compatible with the culture of the developers, but up to a point.
If you think this is a fixed constraint, then no evolution will occur in the field, and we will often find this argument used to justify laggards, late adopters, who often praise themselves as being "innovators".
Take everything with a grain of salt.
Absolute perfection does not exist, but there are different degrees of difficulty.
No chef wants to cut sushi with a blunt knife.
Today maybe I would not advocate using Rust in a corporate back-end.
But I know first hand that Go has earned its place in this domain.
It might be surprising for some managers that the human factors, team dynamics and interactions make software project development difficult.
You might be wasting a large part of your resources or be getting inferior results.
Maybe you thought you could randomly put together teams based on the technical knowledge of their members and hope for the best.
Or your company might even be paying some consultant who promised to deliver "better, more cohesive teams", only to discover that no innovations and creativity are coming out of those teams.
You might be aware that results are not what you expected, project completion takes wildly longer than you could afford, and you know you are wasting money and resources. You are not alone.
This blog is about those pesky human factors and culture in technological organisations.
It also addresses my thoughts on software and software architecture.
Somewhere in London (Usually)
Suggestion: Message me on LinkedIn.