I can tell about bad development habits from using the software it because code smell (and process smell) stinks.
Besides, I was telling not about car repair per se, but about the process around car repairing, which is visible when you visit car workshop and talk to the guys, and is even more visible when you use the software.
Concrete examples:
- installation/upgrade process involving interactive scripts means that somebody thought dumbing down such process for a tiny percent of less-tech users is ok, disregarding the majority who automate everything (and interactive scripts are obviously harder to automate); it also can be a sign that vendor's decision maker (product owner) is disconnected from reality
- poor documentation; a distinct case here is when part of the product is an API and of course "there is" documentation, generated by Swagger - but the crucial part of it are some subtleties of arguments passed which are themselves undocumented, making the whole API simply unusable. The vendor has an excuse "but we have documentation" - heck yes, it's because your employees hate their superiors so they gave them something to f*ck off; and this is given to the customer. Very common practice actually, I can give you a list of vendors who notoriously do that
- painfully slow webapps are a sign of a process smell that no one thinks about the real world operations; sometimes it's not even about scalability, but bad choice/usage of libraries; i need to give here names, in rot13 so it's not googlable: Argfhvgr has a HR product for corporations where every single damn click on any active field in the browser - and you click it a lot because it is fscking calendar - triggers a series of round trips to the server, each taking over 2 seconds. The usability of this product is so braindead at so many levels that I can see a whole bunch of teams failing to stop this sh*t from being released & sold.
Long story but a good example that just by using the product you can see how rotten the vendor must be
I can tell about bad development habits from using the software it because code smell (and process smell) stinks.
Besides, I was telling not about car repair per se, but about the process around car repairing, which is visible when you visit car workshop and talk to the guys, and is even more visible when you use the software.
Concrete examples:
- installation/upgrade process involving interactive scripts means that somebody thought dumbing down such process for a tiny percent of less-tech users is ok, disregarding the majority who automate everything (and interactive scripts are obviously harder to automate); it also can be a sign that vendor's decision maker (product owner) is disconnected from reality
- poor documentation; a distinct case here is when part of the product is an API and of course "there is" documentation, generated by Swagger - but the crucial part of it are some subtleties of arguments passed which are themselves undocumented, making the whole API simply unusable. The vendor has an excuse "but we have documentation" - heck yes, it's because your employees hate their superiors so they gave them something to f*ck off; and this is given to the customer. Very common practice actually, I can give you a list of vendors who notoriously do that
- painfully slow webapps are a sign of a process smell that no one thinks about the real world operations; sometimes it's not even about scalability, but bad choice/usage of libraries; i need to give here names, in rot13 so it's not googlable: Argfhvgr has a HR product for corporations where every single damn click on any active field in the browser - and you click it a lot because it is fscking calendar - triggers a series of round trips to the server, each taking over 2 seconds. The usability of this product is so braindead at so many levels that I can see a whole bunch of teams failing to stop this sh*t from being released & sold. Long story but a good example that just by using the product you can see how rotten the vendor must be