3 ms·

One possibility is this - the people who mess with Excel VBA are generally very smart folk who just never went too techy, but then got really good at Excel and

One possibility is this - the people who mess with Excel VBA are generally very smart folk who just never went too techy, but then got really good at Excel and just learned vba as the next logical step. That means the code might not be kosher but it will be thoughtfully written and encompassing all the practical use cases. Contrast that with a 20something can grad who while competent isn't as smart as that non tech guy, and has indoctrinated the cs way of doing things w.r.t. test coverage and unit tests but often will lack the insight of what the program is actually trying to do. Frankly I would also like to choose the former than the latter.

chii 8y ago
I challenge you to make changes to a spreadsheet or VBA program that isn't using modern programming methods like unit testing and version control. They would turn into a huge mess unless the coder is very diligent and understand every part. CS 'indoctrination' is not a failure of education. Surgeons have been 'indoctrinated' to know pre-op procedures.
- ramraj07 8y ago
  CS indoctrination is most definitely not a failure of education. Mediocre kids thinking they are writing good code because they've written unit tests is. EDIT: Let me explain my thinking a bit more - we can try to categorize software development into two categories: 1. People write messy, unorganized code that is often in the head of just one or a few folks, who are smart but unorganized and often without formal CS training. The code often has almost no tests and doesn't follow any of the standard best practices of software engineering. The code is often impossible to pass down to new people, often ending up forcing the new people to redo a large fraction of the work. 2. People write clean, modular, testable code with good unit and integration tests, a robust build framework, etc. The code is written in a manner thats super easily transferable, most devs don't even have to understand the entire codebase to start meaningfully contributing. Obviously, the second category is the preferred category. A good SDE with a CS bg should follow (and often do follow) the second method. However, category 2 could, at least from my experience, be split into two sub-categories: 2A. The framework for both the code and the dev ecosystem was laid down by (often just one) really good engineers who think through what the problem really is and make sure that the fundamental structure and architecture of the codebase works towards solving that real world problem. This kind of code is absolute pleasure to work with and extend. 2B. The framework and the majority of the code are written by average engineers; often the first few eng hires in the company put the groundwork and make poor design choices and the engineering team that follows never wants to change anything fundamental because that's "tech debt" which the company can never afford to take a step back and look at. The average engineers have a good heart, but often their test cases never test real-world edge cases, they often don't even remember the architecture of the code they themselves wrote a few months back, and the code breaks all the time. Furthermore, the engineers would generally balk at adding any new feature because the codebase is fundamentally evolved into something that just cannot be extended without significant rework, and often they cant even see how they can rework it to add the required feature. In the end, good SDE practices and testing doesn't do shit if the person who wrote it didn't think hard enough. Here again, 2A is the preferred method of doing dev, but unfortunately, the thoughtful smart SDEs aren't that many, and would often be found in a well-paid job in a big company. Most regular devs can't step up to that level and the end result is 2B happens. Now the question is, which is the better of the two evils, if they are the only choices? 1 or 2B? I'd choose 1. My experience has been that while the scrappy code is unmaintenable by anyone new, at the least the guys who wrote it (assuming you can keep them long enough) will at least own up to it and make sure it keeps running, and they can at least try (and practically, generally succeed) to ship a new feature as opposed to the 2B case where often the categorical answer would be no.
  - rgoulter 8y ago
    http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm... This point reminds me of "Portait of a Noob". For people who understand what the codebase is doing, it's more effective to have as much code on screen as possible. For "noobs", since you don't know what the code does, less code on screen is better. Additionally, these 'noobs' like more meta-program stuff like type declarations (or unit tests) which don't actually contribute to the program itself, but provide a safety barrier to prevent things from going wrong. (Whereas, if you know what the code is doing and it goes wrong, you can just fix it). It's fair to say "a program not covered by unit tests can still be good enough to get the job done" (& to suggest that this is under-appreciated), but not having sufficient test coverage significantly raises the barrier to entry for those not familiar with the code ("noobs") from contributing. (EDIT: I wrote my comment before parent's edit)
    - nightski 8y ago
      Is that really true though? Comprehensive test coverage will definitely give the new programmers confidence, but is it justified? Are there really that many software projects where lots of tests instills confidence that changes won't break things? At the end of the day, unit tests or not - you have to understand the code you are working in. This means new programmers will not deliver features as fast as those who have been working on the project for a while. They are going to need to learn the code base regardless of whether it has tests or not.
      - ramraj07 8y ago
        There was a post on HN about Oracle's DB2 code being completely in C and fully unitelligible. Only an insane suite of semi integration tests allows them to maintain it, albeit in the most inefficient way.
        tjalfi 8y ago
        Is [0] the comment you are referring to? [0] https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941
deleted 8y ago
[deleted]
cm2187 8y ago
A good recent example of that. We were asking a dev team to build a dashboard (we are a bank) showing capital ratios. The team came back saying voila! We looked at it, and the headline number in bold at the centre of the dashboard was showing a cet1 ratio of 1300% (a cet1 ratio is typically in the 5%-20% range). I am sure they used modern programming techniques, but they left an error that would have shocked even the least sophisticated user. I have many similar annecdotes. Having a good understanding of the underlying domain and what numbers to expect is critical to writing correct models and too often I see dev teams in banks that have no understanding or curiosity of what they work on.
- antpls 8y ago
  On the other hand, a dashboard is probably one of the most boring stuff to work on when you have a CS degree. Typically, a dashboard is asked as a deliverable to keep the dev team busy while also making sure other people's jobs in the bank arent rendered obsolete if the dev team were used to its full potential. The people saying Devs dont do enough effort to understand the domain are the same people who try to keep the "domain" overly complicated to justify their jobs/positions
  - angry_octet 8y ago
    You're right, a dashboard is a project for when you don't know if they can do anything useful. I think the fault is actually the split between IT (a support function) and the product group, which often doesn't have/isn't allowed embedded devs. IT managers are often toxic for delivering, never take ownership, SLA bullshit, too much PRINCE2 and ITIL. If you can get developers embedded, huge wins are possible. But they have to bring the client with them, not code away in isolation.
  - nerdponx 8y ago
    That's because a dashboard is easy (boring) if you code it up right. Whereas in Excel it's wizardry.
- jrumbut 8y ago
  This is such a common pathology it does cast doubt on the entire field of software development but I would like to note it's been pretty commonly spread and now many years old best practice to have real users in constant communication and perhaps colocated with developers. This is a very predictable outcome when a requirements doc is tossed over the wall followed by patient waiting for the output. Again, it happens all the time so maybe this advice isn't enough or practical or something, but there is a well recognized solution and I would wonder whether it was done in this project.
gizmo686 8y ago
Still, when you have a team of very smart folk writing complicated bussiness critical software in Excell, it is a good indication that you should invest in training those people in more proper programming languages.
- cm2187 8y ago
  Agree. I am trying to get bankers to learn programming by offering them free courses.

chii 8y ago

I challenge you to make changes to a spreadsheet or VBA program that isn't using modern programming methods like unit testing and version control. They would turn into a huge mess unless the coder is very diligent and understand every part. CS 'indoctrination' is not a failure of education. Surgeons have been 'indoctrinated' to know pre-op procedures.

ramraj07 8y ago
CS indoctrination is most definitely not a failure of education. Mediocre kids thinking they are writing good code because they've written unit tests is. EDIT: Let me explain my thinking a bit more - we can try to categorize software development into two categories: 1. People write messy, unorganized code that is often in the head of just one or a few folks, who are smart but unorganized and often without formal CS training. The code often has almost no tests and doesn't follow any of the standard best practices of software engineering. The code is often impossible to pass down to new people, often ending up forcing the new people to redo a large fraction of the work. 2. People write clean, modular, testable code with good unit and integration tests, a robust build framework, etc. The code is written in a manner thats super easily transferable, most devs don't even have to understand the entire codebase to start meaningfully contributing. Obviously, the second category is the preferred category. A good SDE with a CS bg should follow (and often do follow) the second method. However, category 2 could, at least from my experience, be split into two sub-categories: 2A. The framework for both the code and the dev ecosystem was laid down by (often just one) really good engineers who think through what the problem really is and make sure that the fundamental structure and architecture of the codebase works towards solving that real world problem. This kind of code is absolute pleasure to work with and extend. 2B. The framework and the majority of the code are written by average engineers; often the first few eng hires in the company put the groundwork and make poor design choices and the engineering team that follows never wants to change anything fundamental because that's "tech debt" which the company can never afford to take a step back and look at. The average engineers have a good heart, but often their test cases never test real-world edge cases, they often don't even remember the architecture of the code they themselves wrote a few months back, and the code breaks all the time. Furthermore, the engineers would generally balk at adding any new feature because the codebase is fundamentally evolved into something that just cannot be extended without significant rework, and often they cant even see how they can rework it to add the required feature. In the end, good SDE practices and testing doesn't do shit if the person who wrote it didn't think hard enough. Here again, 2A is the preferred method of doing dev, but unfortunately, the thoughtful smart SDEs aren't that many, and would often be found in a well-paid job in a big company. Most regular devs can't step up to that level and the end result is 2B happens. Now the question is, which is the better of the two evils, if they are the only choices? 1 or 2B? I'd choose 1. My experience has been that while the scrappy code is unmaintenable by anyone new, at the least the guys who wrote it (assuming you can keep them long enough) will at least own up to it and make sure it keeps running, and they can at least try (and practically, generally succeed) to ship a new feature as opposed to the 2B case where often the categorical answer would be no.
- rgoulter 8y ago
  http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm... This point reminds me of "Portait of a Noob". For people who understand what the codebase is doing, it's more effective to have as much code on screen as possible. For "noobs", since you don't know what the code does, less code on screen is better. Additionally, these 'noobs' like more meta-program stuff like type declarations (or unit tests) which don't actually contribute to the program itself, but provide a safety barrier to prevent things from going wrong. (Whereas, if you know what the code is doing and it goes wrong, you can just fix it). It's fair to say "a program not covered by unit tests can still be good enough to get the job done" (& to suggest that this is under-appreciated), but not having sufficient test coverage significantly raises the barrier to entry for those not familiar with the code ("noobs") from contributing. (EDIT: I wrote my comment before parent's edit)
  - nightski 8y ago
    Is that really true though? Comprehensive test coverage will definitely give the new programmers confidence, but is it justified? Are there really that many software projects where lots of tests instills confidence that changes won't break things? At the end of the day, unit tests or not - you have to understand the code you are working in. This means new programmers will not deliver features as fast as those who have been working on the project for a while. They are going to need to learn the code base regardless of whether it has tests or not.
    - ramraj07 8y ago
      There was a post on HN about Oracle's DB2 code being completely in C and fully unitelligible. Only an insane suite of semi integration tests allows them to maintain it, albeit in the most inefficient way.
      - tjalfi 8y ago
        Is [0] the comment you are referring to? [0] https://news.ycombinator.com/item?id=18442941 https://news.ycombinator.com/item?id=18442941

deleted 8y ago

[deleted]

cm2187 8y ago

A good recent example of that. We were asking a dev team to build a dashboard (we are a bank) showing capital ratios. The team came back saying voila! We looked at it, and the headline number in bold at the centre of the dashboard was showing a cet1 ratio of 1300% (a cet1 ratio is typically in the 5%-20% range). I am sure they used modern programming techniques, but they left an error that would have shocked even the least sophisticated user. I have many similar annecdotes. Having a good understanding of the underlying domain and what numbers to expect is critical to writing correct models and too often I see dev teams in banks that have no understanding or curiosity of what they work on.

antpls 8y ago
On the other hand, a dashboard is probably one of the most boring stuff to work on when you have a CS degree. Typically, a dashboard is asked as a deliverable to keep the dev team busy while also making sure other people's jobs in the bank arent rendered obsolete if the dev team were used to its full potential. The people saying Devs dont do enough effort to understand the domain are the same people who try to keep the "domain" overly complicated to justify their jobs/positions
- angry_octet 8y ago
  You're right, a dashboard is a project for when you don't know if they can do anything useful. I think the fault is actually the split between IT (a support function) and the product group, which often doesn't have/isn't allowed embedded devs. IT managers are often toxic for delivering, never take ownership, SLA bullshit, too much PRINCE2 and ITIL. If you can get developers embedded, huge wins are possible. But they have to bring the client with them, not code away in isolation.
- nerdponx 8y ago
  That's because a dashboard is easy (boring) if you code it up right. Whereas in Excel it's wizardry.
jrumbut 8y ago
This is such a common pathology it does cast doubt on the entire field of software development but I would like to note it's been pretty commonly spread and now many years old best practice to have real users in constant communication and perhaps colocated with developers. This is a very predictable outcome when a requirements doc is tossed over the wall followed by patient waiting for the output. Again, it happens all the time so maybe this advice isn't enough or practical or something, but there is a well recognized solution and I would wonder whether it was done in this project.

gizmo686 8y ago

Still, when you have a team of very smart folk writing complicated bussiness critical software in Excell, it is a good indication that you should invest in training those people in more proper programming languages.

cm2187 8y ago
Agree. I am trying to get bankers to learn programming by offering them free courses.