4 ms·

Honestly, it just sounds like you are bad at managing your own software projects and trying to blame it on the web team. If your code had been as easy to under

by gjolund 10y ago

Honestly, it just sounds like you are bad at managing your own software projects and trying to blame it on the web team. If your code had been as easy to understand as you say it is there would have been no need to re-write it. Also, your acknowledgement that it was difficult to maintain makes my point for me.

edejong 10y ago
It wasn't written to be easily maintainable, as it was a PoC. So no comments, relatively short naming. However, it had good SoC and simple logic to update views. Minimal, but understandable. I wanted it to be rewritten before I wrote the first line of code. My trust went to someone who does full-time web development (I'm alround, full-stack).
- gjolund 10y ago
  What is the argument here? You wrote a POC of unmaintainable code, and then some junior web devs butchered your project because it was undocumented and "understandable" to you only. Get off your high horse. If I was your boss I would be asking why you didn't speak up earlier, and why you didn't document your work better.
  - edejong 10y ago
    The (beta) protocol was pretty well documented at the time and it took relatively little time to implement the iOS client. 2000 lines of code is relatively easy to understand, even without someone explaining what's going on. The project wasn't a failure at all. Currently being used in a production setting for communication in and between hospitals and medical labs.
  - sgift 10y ago
    > You wrote a POC of unmaintainable code Going from "not written to be easily maintainable" to "unmaintainable" is exactly the problem you see very often. Instead of investing a bit of time to learn things and make them incrementally better people cry foul when it's not perfectly to their liking (i.e. if they haven't written it themself) and tell you later when you ask them if that monstrosity they've written was really necessary - which probably doesn't work and/or has bugs which had been already fixed in the original codebase - that it was "unmaintanable" and so they "had" to rewrite it.
braythwayt 10y ago
> If your code had been as easy to understand as you say it > is there would have been no need to re-write it. In theory, only difficult-to-understand and/or difficult-to-maintain code is rewritten. In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. I wouldn’t assume there’s any correlation whatsoever between the quality, readability, or maintainability of code and whether it gets rewritten when a new team arrives. Sometimes, that’s just what happens, whether we think it’s justified or not.
- deleted 10y ago
  [deleted]
- jonathankoren 10y ago
  This. I've seen thing rewritten for purely political purposes more often than technical reasons.
  - exodust 10y ago
    Same here. I've also seen the re-written code perform no better than the original but nevertheless celebrated as improved. I guess when billable hours are at the heart, nobody wants to say "and we rebuilt the homepage for what turned out to be no reason at all, but kept us busy for a few weeks".
- morgante 10y ago
  > In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. And that's perfectly valid. In fact, it's one of the best reasons to use a framework. If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc. On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React. That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.

by gjolund 10y ago

edejong 10y ago

It wasn't written to be easily maintainable, as it was a PoC. So no comments, relatively short naming. However, it had good SoC and simple logic to update views. Minimal, but understandable. I wanted it to be rewritten before I wrote the first line of code. My trust went to someone who does full-time web development (I'm alround, full-stack).

gjolund 10y ago
What is the argument here? You wrote a POC of unmaintainable code, and then some junior web devs butchered your project because it was undocumented and "understandable" to you only. Get off your high horse. If I was your boss I would be asking why you didn't speak up earlier, and why you didn't document your work better.
- edejong 10y ago
  The (beta) protocol was pretty well documented at the time and it took relatively little time to implement the iOS client. 2000 lines of code is relatively easy to understand, even without someone explaining what's going on. The project wasn't a failure at all. Currently being used in a production setting for communication in and between hospitals and medical labs.
- sgift 10y ago
  > You wrote a POC of unmaintainable code Going from "not written to be easily maintainable" to "unmaintainable" is exactly the problem you see very often. Instead of investing a bit of time to learn things and make them incrementally better people cry foul when it's not perfectly to their liking (i.e. if they haven't written it themself) and tell you later when you ask them if that monstrosity they've written was really necessary - which probably doesn't work and/or has bugs which had been already fixed in the original codebase - that it was "unmaintanable" and so they "had" to rewrite it.

braythwayt 10y ago

> If your code had been as easy to understand as you say it > is there would have been no need to re-write it. In theory, only difficult-to-understand and/or difficult-to-maintain code is rewritten. In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. I wouldn’t assume there’s any correlation whatsoever between the quality, readability, or maintainability of code and whether it gets rewritten when a new team arrives. Sometimes, that’s just what happens, whether we think it’s justified or not.

deleted 10y ago
[deleted]
jonathankoren 10y ago
This. I've seen thing rewritten for purely political purposes more often than technical reasons.
- exodust 10y ago
  Same here. I've also seen the re-written code perform no better than the original but nevertheless celebrated as improved. I guess when billable hours are at the heart, nobody wants to say "and we rebuilt the homepage for what turned out to be no reason at all, but kept us busy for a few weeks".
morgante 10y ago
> In practice, the definition for “difficult-to-understand” and “difficult-to-maintain” often boil down to whatever the team decides they are familiar with... Or want to be familiar with. And that's perfectly valid. In fact, it's one of the best reasons to use a framework. If I hand-roll my application with a cobbled-together framework, I am the only one who understands how it works. Even if I'm a pretty great developer and write very clean code, there is an inherent complexity cost to any code—whoever comes on board will have to learn how I'm tracking state, managing the DOM, etc. On the other hand, if I just wrote it in React I could be fairly confident that another web developer could pick up the project and easily understand how things are working with minimal effort. They've likely already paid the complexity cost of understanding React. That's what the article and OP entirely miss. We don't use frameworks to improve the speed of the application. We don't even use frameworks to improve the speed of development. We use frameworks to improve the speed of understanding.