Why are our platforms So Crappy?
https://www.reddit.com/r/ProgrammerHumor/comments/6rdafy/how_crappy_software_proliferates_xpost_xkcd/

Why are our platforms So Crappy?

A few weeks ago I read an article about “Why is advertising so crappy” and I couldn’t help but think of a similar one called “Why are our platforms so crappy?”. So here it is! 

Have you realised how often you join a company, or talk with a friend, or in any meetup, and there is a kind of competition about where you found the worst platform ever ? We are computer engineers and we love complaining, but there is truly crappy software all around. To Be honest, it is easier to find bad software than good one.

It is clear that we have a problem in our profession about the quality of our products and I′ve had multiple and long discussions about why this happens. Here are my thoughts: 

  • The first one is that software changes. We need new features, or updated frameworks or it needs to scale because the number of customers is always growing. Writing static code is easy, as far as it meets initial requirements any structure is good enough. The problem is writing code that allows changes , and here is where the problems come as, in most cases, having this kind of code is everything but intuitive. If you have nobody in the team with that experience you will make mistakes, some of them really difficult to fix, and this often happens .
  • Another point is that complex code is an enemy of good code and, I am not sure why, we tend to think that the more complex code we produce the better engineers we are. In that book that we all have thought about writing containing hilarious situations we have lived in, I have some anecdotes from code review sessions or comments that reflect really well what I am trying to describe. Sometimes people ended up so lost that nobody said anything (including me) thinking that it was clearly because I wasn′t experienced enough or simply because I was stupid. After some years I’ve learned that the problem wasn't us but the code itself and, related to the first point, when you have to change complex code you tend to duplicate or change things you shouldn't change. As I said before, changes will come and code has to be easy to change, or at least as easy as possible. There are a number of patterns you can work with, but being in the the right place is difficult. You want to have code you can change, but over-engineering is as bad as not being ready to adapt.
  • One of my favorites is the ferrari complex. We all want to use the last technology, the best patterns, and some weird frameworks we find around, so we are ready in case we manage to get millions of customers. When we have to transport goods from one place to another we buy a truck, even if driving a ferrari is way more exciting. The same thing happens with software, and we need to adapt to our needs. One example: we probably need microservices in a startup when we are building our platform, and we need to be as quick as possible to be in the market ASAP. Starting with something simple and then adapting sounds to me like a better choice. Another example I found everywhere is that the platform is not our playground. I don't want to say that there is no space to investigate and try new things, but probably MongoDB is not a good choice if you have nobody in the company with experience. If we believe it is the best option, it helps having a freelancer to advise, or maybe you need to hire someone.
  • Technical leadership has to be, in my opinion, the biggest defender of business within the IT department and that means compromising and finding the right technology to support company goals, not more, no less. Sometimes we forget this and we start acting as I described previously. Having fun and working with cool technology is good, but our work is to help other departments with what they require to run our business.
  • Probably there are more, but this is the last one from my side… for now. I had some doubts about adding this point or not, but I believe lack of processes, mixing waterfall, agile, chaos is a big other reason why our platforms are so crappy. I strongly believe in agile methodologies, but we have to admit we have messed it up a bit. We are moving in one direction but companies move in another and it creates a lot of problems. Having a different perspective ends up in having wrong estimations and expectations. The outcome of this is frustration and having to cut corners to be able to finish a project or a feature on time. 



I haven’t added the classical “we keep having unrealistic deadlines” because it is the ONE reason we, technical people, use to answer when we′re asked about our platform, but being fair that’s the same everywhere and you can manage and compromise. I believe we have more to say and a lot of improvements on our side before we contemplate any external reason why we don′t like our platform.

Software always has problems - if it isn't evolving, it means that the business is not growing, adapting, moving. It is human nature to focus on the negative and forget all of the stuff that just happens. If the software is functioning in live and enabling the business to generate positive revenue, can it ever be called "crappy"?

回复

要查看或添加评论,请登录

Borja Aguado Badillo的更多文章

  • They vs Us - Can we fix the friction between IT and business?

    They vs Us - Can we fix the friction between IT and business?

    There are some common messages I get talking with people in companies, it doesn’t matter if they are technical people…

  • How technology has changed society and companies

    How technology has changed society and companies

    If I have to think about some of the characteristics of our society in 2020, one has to be how we are used to getting…

  • Requirements in agile methodology

    Requirements in agile methodology

    On the 12th of February 2001 the Agile Manifesto was published, and after that everything changed regarding how we…

    1 条评论
  • Behaviour Driven Development

    Behaviour Driven Development

    If we read the definition of Behaviour-driven development in Wikipedia we will find this: “In software engineering…

    3 条评论
  • What we can learn from waterfall.

    What we can learn from waterfall.

    There is almost a unanimous consensus that agile methodologies are the best approach when we want to have quick…

    2 条评论
  • Contract testing

    Contract testing

    Years ago I watched one conference that changed my view on how to approach testing. It is a conference called…

  • My first steps transitioning to Continuous Delivery

    My first steps transitioning to Continuous Delivery

    Have you ever left an event or talk where Continuous Delivery has been discussed thinking… such good ideas, I’d love to…

    7 条评论

社区洞察

其他会员也浏览了