5 ms·

Yes, simplicity leads to understanding and I don't understand why more people don't get this simple concept. I've dealt with codebases with such a horrendous bu

Yes, simplicity leads to understanding and I don't understand why more people don't get this simple concept. I've dealt with codebases with such a horrendous build process that it doesn't matter what kind of sugar you sprinkle on top because making any change is practically impossible. That complexity has to live somewhere and if you offload it to the docker buildfile it's still in the buildfile. The problem at the end of the day comes down to the fact that most developers either don't understand enough to build proper build pipelines or they are lazy or they don't think complexity in the build pipeline is anything to worry about. Docker does not change those things.

bdamm 12y ago
What if the problem actually is complex? Let's say that I'm building an embedded firmware module for a chipset that can only be compiled with a proprietary compiler under Visual Studio - and you're a Unix shop with Bamboo as the continuous integration server? Then that means the Unix bamboo server needs a Windows agent that can execute the cross-compiler inside a MS VC environment. It certainly is complex, but what piece are you going to change?
- fragmede 12y ago
  Honestly? Port it to GCC. (Easier than LLVM, IMO) That, or switch to a different chipset, this time taking care to select something that includes unix build tools. Neither of those is trivial, nor are they cheap. But rewriting their simulator in C, as described in the article, couldn't have been cheap either.
  - new299 12y ago
    Perhaps the instruction set is undocumented? (it happens). Alternative chipsets cost x10 (also happens, and is probably correlated to documentation quality). Price is an important factor, and the messy choice is often not unreasonable.
- plorkyeran 12y ago
  Why are you a unix shop if using Visual Studio is a hard requirement? The complexity is entirely due to you choosing tools that work poorly together, so instead pick tools that work well with the ones you can't change.
  - new299 12y ago
    Seems like you're suggesting running a completely separate parallel build platform for one project. The parent seems to have taken the pragmatic, but messier choice. Sometimes, there just aren't good clean solutions, and you have to be messy and pragmatic. That, of course, is often used as an excuse for being lazy as well.
- cyberpanther 12y ago
  You are always going to have complexity, but we often forget to simplify before adding on more layers and tools on to our processes. I singled out Docker in particular because it is so awesome and powerful, I feel like a lot of people are just using it to cover up crappy processes. Eventually that is going to come back to haunt you in terms of slower development.
dkarl 12y ago
I agree completely, and I think git vs. CVS is a good illustration of why people don't always understand the value of it. From a certain point of view, branching and merging was easier for most developers under CVS, because they never had to do it. It was a Big Deal and was done by special people. If you tell someone who is using CVS and never deals with branching and merging that they're switching to git, and oh, by the way, they'll be doing their own branching and merging from now on, that sounds like a horrible step backwards to them. Telling someone that you're going to make something difficult accessible to them can sound extremely threatening.
- bch 12y ago
  I think the gist of your sentiment is that barriers to entry aren't necessarily bad. I agree. I disagree that dscm (as a satisfied fossil user, I refuse to call these general concepts "git concepts") is the way to describe it though. I feel a closer analogy (from experience) is papering over horrible app performance by throwing up a proxy like varnish. You've still got garbage under the hood.
  - dkarl 12y ago
    I don't mean to agree with people who resist this type of change, just to explain how it looks from their point of view. A CVS user sees branching and merging as a difficult, painful, time-consuming things to be avoided, so they're horrified if you tell them they're going to be branching and merging on a daily basis. They aren't right — generalizing from their CVS experience has given them a mistaken idea of what using git (or fossil) is like — but it's easy to understand why they're afraid. Also, ironically and unfortunately, the fact that a git (or fossil) advocate is enthusiastic about the ease of branching and merging is likely to make the CVS user think they are crazy, since you'd have to be crazy to love branching and merging in CVS.
bottled_poe 12y ago
>Yes, simplicity leads to understanding and I don't understand why more people don't get this simple concept. I too have seen this time and time again. It pops up constantly in poorly managed software projects, especially those that have changed hands over years. In addition to this, I believe simplicity is lost because many engineers/managers struggle to step back from the their immediate task and instead visualize the whole system in its entirety. This is difficult and takes a special combination of knowledge and procedure to do well.
Spooky23 12y ago
Chronic complexity is usually job security for someone.

bdamm 12y ago

What if the problem actually is complex? Let's say that I'm building an embedded firmware module for a chipset that can only be compiled with a proprietary compiler under Visual Studio - and you're a Unix shop with Bamboo as the continuous integration server? Then that means the Unix bamboo server needs a Windows agent that can execute the cross-compiler inside a MS VC environment. It certainly is complex, but what piece are you going to change?

fragmede 12y ago
Honestly? Port it to GCC. (Easier than LLVM, IMO) That, or switch to a different chipset, this time taking care to select something that includes unix build tools. Neither of those is trivial, nor are they cheap. But rewriting their simulator in C, as described in the article, couldn't have been cheap either.
- new299 12y ago
  Perhaps the instruction set is undocumented? (it happens). Alternative chipsets cost x10 (also happens, and is probably correlated to documentation quality). Price is an important factor, and the messy choice is often not unreasonable.
plorkyeran 12y ago
Why are you a unix shop if using Visual Studio is a hard requirement? The complexity is entirely due to you choosing tools that work poorly together, so instead pick tools that work well with the ones you can't change.
- new299 12y ago
  Seems like you're suggesting running a completely separate parallel build platform for one project. The parent seems to have taken the pragmatic, but messier choice. Sometimes, there just aren't good clean solutions, and you have to be messy and pragmatic. That, of course, is often used as an excuse for being lazy as well.
cyberpanther 12y ago
You are always going to have complexity, but we often forget to simplify before adding on more layers and tools on to our processes. I singled out Docker in particular because it is so awesome and powerful, I feel like a lot of people are just using it to cover up crappy processes. Eventually that is going to come back to haunt you in terms of slower development.

dkarl 12y ago

I agree completely, and I think git vs. CVS is a good illustration of why people don't always understand the value of it. From a certain point of view, branching and merging was easier for most developers under CVS, because they never had to do it. It was a Big Deal and was done by special people. If you tell someone who is using CVS and never deals with branching and merging that they're switching to git, and oh, by the way, they'll be doing their own branching and merging from now on, that sounds like a horrible step backwards to them. Telling someone that you're going to make something difficult accessible to them can sound extremely threatening.

bch 12y ago
I think the gist of your sentiment is that barriers to entry aren't necessarily bad. I agree. I disagree that dscm (as a satisfied fossil user, I refuse to call these general concepts "git concepts") is the way to describe it though. I feel a closer analogy (from experience) is papering over horrible app performance by throwing up a proxy like varnish. You've still got garbage under the hood.
- dkarl 12y ago
  I don't mean to agree with people who resist this type of change, just to explain how it looks from their point of view. A CVS user sees branching and merging as a difficult, painful, time-consuming things to be avoided, so they're horrified if you tell them they're going to be branching and merging on a daily basis. They aren't right — generalizing from their CVS experience has given them a mistaken idea of what using git (or fossil) is like — but it's easy to understand why they're afraid. Also, ironically and unfortunately, the fact that a git (or fossil) advocate is enthusiastic about the ease of branching and merging is likely to make the CVS user think they are crazy, since you'd have to be crazy to love branching and merging in CVS.

bottled_poe 12y ago

>Yes, simplicity leads to understanding and I don't understand why more people don't get this simple concept. I too have seen this time and time again. It pops up constantly in poorly managed software projects, especially those that have changed hands over years. In addition to this, I believe simplicity is lost because many engineers/managers struggle to step back from the their immediate task and instead visualize the whole system in its entirety. This is difficult and takes a special combination of knowledge and procedure to do well.

Spooky23 12y ago

Chronic complexity is usually job security for someone.