Forget Technical Debt - Comments, Phishing trap

Post date: Sep 25, 2016 3:32:52 PM

• Forget Technical Debt - Yet another great article about this topic. It's like with every other thing, there's no single 'right' solution which would be better than all other options. I really liked lack of tests and naming issues. Naming issues are legendary. Often some features got totally and absolutely misleading names. Making it's practically impossible to figure out what it does, unless you know exactly what it is all about. Culture of messing things up, doesn't limit to code alone. It's an overall process as they say. If everything is totally messed up before it comes to the coders, the situation is already pretty bad. Reasons for things being totally messed up are varying and in some cases it feels like being the norm. It's hard to write tests for cases which are actually unknown when the code is being written. Unfortunately it's quite common that stuff is being developed without knowing what it should do. Don't ask, it's just that way. This is awesome point: Write and run unit, acceptance, approval, and integration tests. - It would be so nice if it would be possible. But in most of cases, customers don't appreciate it and therefore these things aren't getting done, because nobody's paying for those. - When you rented your small economy car for a day, did they have professional racing driver to check tire pressures, adjust shock absorbers and run break tests on bench? They didn't? Why did you rent the care from that car rental shop? It would be so nice to make awesome stuff, but as said in world of super cars, it's very limited market. It's like the acceptance testing, most of customers can't produce any kind of clear test cases anyway. Some customers can, and that's awesome luxury. But in most cases, especially if behind schedule, let's just put it into production and fix it later if something breaks down. In that case it's easy to say, something will break down. But that's what you're asking for. Hurtling toward entropy doesn't have anything to do with programming or code. It's totally normal thing with any process not being properly managed. I often find out that it's funny that they're talking about code. It doesn't matter what the process or task is. If it's not being properly managed, it's going to be one big entropy. Let's say something simple like invoicing or stock management. Those will fail just like code, if things aren't being under tight control, checks and process guides being followed. As POS guy, it's really common to see peole saying that your stock keeping code isn't working. When you check from logs, everything works. They'll agree with you. They just don't want to immediately say that their staff is stealing or they don't simply bother to input the stock transactions. After that it's totally natural that stock is messed up. What's the surprise there? Actually it's quite interesting to see how large chains can totally screw up their stock management & logistics. Yet in this article, all tips are good. It's always just very important (and hard) to know what are the points which are worth of extra work. It's like the Efficient Frontier in investing. If small start-up launches and spends 10 years building their ultimate on cloud infrastructure and platform to build their services on, it's not probably going to go very well. Also project & team size is essential question here. Continuous Delivery is something I think should be obvious, but in many cases companies are actually making the release cycle more sparce so things 'can be tested properly'. Which of course means that the automated testing is lacking as well as automated build, update and rollback stuff. This just makes all the development iterations way slower and updates larger. Which means that when you finally release the 'great new version' everyone's been waiting, it's actually going to be more like running a nuclear bomb test. After that there will be panic to get the most deliberating issues fixed. Which will be fixed hastily, causing yet more trouble and things to fix. I've gotta be honest, I've been laughed at when I said that automatic scaling of computing resources would be smart. It's impossible, you know. Some of the examples in the article about archaic projects feel just so painful it's even uncomfortable to read the article. Modern Agile principles sounded great. Yet agility is actually against other things mentioned in this article. Adding all the heavy administrative processes reduce agility a lot. It's always about finding the correct balance for the situation. Makers doing maintenance, been there done that. Actually doing that everyday. I built programs to be maintained, not just 'make it work' and then causing havoc later. I've had to explain that times when something is taking too long or is too expensive. Or I should have gotten something done on extremely bad specification. I do not do something, so I can say it's done. I do things to provide value to the customer and end users. If I don't see it producing value, or working properly, there's no point of doing it. Unless the customer specifically acknowledges and agrees that this is something really crappy and ad-hoc and we can fix it later. Then it's totally acceptable.
• Kraken Phishing Warning. Another great example how easy it's to fall pray to phishing unless you know what you're doing.