5 ms·

I think these types used to be derogatorily referred to as "cowboy coders" in the 90's by overly process oriented developers who came from an era of mainframes

by modarts 13y ago

I think these types used to be derogatorily referred to as "cowboy coders" in the 90's by overly process oriented developers who came from an era of mainframes and punchcards. I think a big shift in modern software development came about when people finally realized that developing software is by nature a "messy" process. Loose text files, REPL sessions filled with red lines on the console, randomly scribbled boxes with arrows on loose sheets of paper strewn about the room; traversing object graphs in your head while on the drive to work. There is no "outline" to frame any of that. The outline only exists after the software has been built.

chris_mahan 13y ago
AMEN!
stephengillie 13y ago
Maybe I've been spoiled by working with embedded C++ on Arduinos, where we have 3 sections -- Initialization, Setup function, and Loop function. We set variables and include libraries in the Initialization section at top. We run first-time code and open serial & other connections in Setup. Most code goes into the Loop section, which is the function that does the heavy lifting. Extra functions (i.e. the math to convert inches to mm) can be written below, and called in either Setup or Loop.
- jared314 13y ago
  This is why programming language history is so important. Every programming language has a large number of opinions/assumptions. Code structure is one of them. The Arduino language, based on C/C++, has assumed a simple code structure that helps people learning embedded programming, because the Arduino platform was designed to help people learn.
pjmlp 13y ago
Sadly that does not work in enterprise multi-site projects with outsourcing across several companies.
- modarts 13y ago
  Yup; which is why the people getting hired for those projects would flounder if asked to make a large individual contribution without much handholding; and also why those types of project team structures yield such incomprehensibly shitty software (at ridiculous cost to the client.)
  - chrisbuc 13y ago
    Seriously? Many of the enterprise devs I know do make large individual contributions in their own (side) projects, or in smaller projects within the organization. Part of enterprise dev is that you are developing within a series of constraints, not least the thought in mind that there is likely to be someone maintaining this code in 10 years time, and it's unlikely to be the team building it today. I would agree about the general outcome, though - enterprise software often is built _despite_ the politics between various departments and vendors, and much of the solution is as a result of compromise and integrating with "not quite suitable for current purpose" legacy systems. That is where a large amount of the cost goes. (It's also important to remember that what we're building today is also going to become the legacy system of tomorrow, and to include that thought in the design).
    - pjmlp 13y ago
      That is also my experience.
cunac 13y ago
developing software is not messy process. what is disturbing is that you think it is and that is normal state. Sure it is messy if you develop by accident so lets see what sticks.
prollyignored 13y ago
> .. messy .. Design is messy. The implementation need not. > “Design Patterns”, “Code architecture”, “Scalability”, “OOP”, “Maintainability” Apart from Scalability others can be implemented from day one. Scalability is about a dumb proxy first. Change in Data structures next. In software, you have two choices. 1) Dumb code that works aka kludge. The author is advocating kludge programming. (I want to use this word distinctly from hacks, which are fewer and atleast clever) I advocate this. 2) SQlite, Games I advocate this too. Software that is meant to last, requires rigor. My point is, the author is considering all programming to be engineering programming. It's not. And I do hate project managers that confuse the two. I even concede that you can mixmatch the two (testing for eg). Why don't people see this middle ground ?

by modarts 13y ago

chris_mahan 13y ago

AMEN!

stephengillie 13y ago

Maybe I've been spoiled by working with embedded C++ on Arduinos, where we have 3 sections -- Initialization, Setup function, and Loop function. We set variables and include libraries in the Initialization section at top. We run first-time code and open serial & other connections in Setup. Most code goes into the Loop section, which is the function that does the heavy lifting. Extra functions (i.e. the math to convert inches to mm) can be written below, and called in either Setup or Loop.

jared314 13y ago
This is why programming language history is so important. Every programming language has a large number of opinions/assumptions. Code structure is one of them. The Arduino language, based on C/C++, has assumed a simple code structure that helps people learning embedded programming, because the Arduino platform was designed to help people learn.

pjmlp 13y ago

Sadly that does not work in enterprise multi-site projects with outsourcing across several companies.

modarts 13y ago
Yup; which is why the people getting hired for those projects would flounder if asked to make a large individual contribution without much handholding; and also why those types of project team structures yield such incomprehensibly shitty software (at ridiculous cost to the client.)
- chrisbuc 13y ago
  Seriously? Many of the enterprise devs I know do make large individual contributions in their own (side) projects, or in smaller projects within the organization. Part of enterprise dev is that you are developing within a series of constraints, not least the thought in mind that there is likely to be someone maintaining this code in 10 years time, and it's unlikely to be the team building it today. I would agree about the general outcome, though - enterprise software often is built _despite_ the politics between various departments and vendors, and much of the solution is as a result of compromise and integrating with "not quite suitable for current purpose" legacy systems. That is where a large amount of the cost goes. (It's also important to remember that what we're building today is also going to become the legacy system of tomorrow, and to include that thought in the design).
  - pjmlp 13y ago
    That is also my experience.

cunac 13y ago

developing software is not messy process. what is disturbing is that you think it is and that is normal state. Sure it is messy if you develop by accident so lets see what sticks.

prollyignored 13y ago

> .. messy .. Design is messy. The implementation need not. > “Design Patterns”, “Code architecture”, “Scalability”, “OOP”, “Maintainability” Apart from Scalability others can be implemented from day one. Scalability is about a dumb proxy first. Change in Data structures next. In software, you have two choices. 1) Dumb code that works aka kludge. The author is advocating kludge programming. (I want to use this word distinctly from hacks, which are fewer and atleast clever) I advocate this. 2) SQlite, Games I advocate this too. Software that is meant to last, requires rigor. My point is, the author is considering all programming to be engineering programming. It's not. And I do hate project managers that confuse the two. I even concede that you can mixmatch the two (testing for eg). Why don't people see this middle ground ?