I've seen a lot of the software engineers on teams I've worked with complain about the way data science and machine learning professionals work with code, and They. Just. Don't. Get. It. Stop trying to push the tools and processes that you developed for yourselves onto us!
People I work with don't care that our notebook tools have rudimentary syntax highlighting or type-checking. We don't rely on our tools to make sure our code is written correctly. We just memorize the APIs and rely on experimentation to get things working.
Please don't make us use git. Checking out and checking in files is too slow! Oftentimes, Slacking code to a colleague is the best way to collaborate, and the fastest.
Don't make us use confusing and broken authentication schemes to access our data! I work best if I can just download live data to my machine and work locally. If it's too big or it's something like streaming, just give me an admin password that I can save in my notebook and use to hit some database clusters. Nothing wrong with that!
This is painfully funny. It's interesting though I feel like it's harder to do data science right because the iterations are so much slower. If it takes all day to run a model it's hard to get in enough reps to really understand what good practices are for the domain.
Yes, oh yes. From what I've seen, many products we've seen fall into one of several categories:
- People thinking if Jupyter notebooks had just the right CSS and animations, it'd make machine learning unstuck.
- People coming from web dev and thinking that ML folks are somehow unaware of Docker/CICD/Kubernetes/Git and if they could just be enlightened, they'd be much more productive.
- People coming from a background of publishing blog posts/Youtube videos about machine learning, or who've worked with cute datasets who think that the actual workflow is someone giving you a CSV and a metric to optimize for à la Kaggle and building something around that workflow. This is for ML what Aikido is for fighting: it only works if your opponent knows the script and agrees to fall when you go Hayaaa!
Disclosure: we're working on our machine learning platform[0] because we desperately need it. We do not come from a web dev or blogging background, and it shows. We're building it because we spent seven years actually delivering machine learning products to paying enterprise in the mid six figures contracts with actual money, trust, and careers on the line. We've done it OK enough to have companies trust us and become repeat customers, but, anyone we faced the problems that anyone who has worked on actual projects has faced. Just getting to formulate the problem is akin to extracting Ramses II's brain through his nostrils. Agreeing on the data to use and then getting the data to a usable form takes a long time. Defining the real world metric is not obvious [if only it just boiled down to F1/AUC/ROC/ETC]. Most things that matter are done by a team, and tools work great for one individual, but break for teams. Just getting results to the client makes the work an endangered specie in an "only one result out of 100 makes it to the client".
It is unbelievable how much these problems impact the team. People can quit over this and we've suffered a lot.
So we're building around our workflow that has generated actual revenues with very large organizations that were satisfied enough to come back for more projects. It is not a perfect workflow, but it is from the real world on real projects and real clients that paid real money to solve real problems.
And we're building it for ourselves to use on actual projects. We aim for 10x improvement.
Aikido does work as a physical activity to stay fit and bond socially, just like gardening and yoga. It's not useless; it's just useless for what most people think it's useful for.
It most definitely is, but there's a large part of truth in it. You can try and train people to write good code or follow best practices but from what I have seen, you're swimming against strong currents.
What we have here is the: "I don't get it, why don't you read this 500 pages manual and type in those 10 commands to print your document" era of computing. People wondered why people had trouble "just" programming something.
That is not the job to be done. There are huge frictions and broken interfaces between roles: developers, engineers, data scientists, domain experts with everyone expecting the other to "just" do X.
If data scientists just wrote better code. If developers just were more familiar with machine learning. If ML engineers just could be more CICD aware. If domain experts just could get it right. This is not working.
> That is not the job to be done. There are huge frictions and broken interfaces between roles: developers, engineers, data scientists, domain experts with everyone expecting the other to "just" do X.
The only friction I see with data analysis roles is that data analysts typically don't need (or even outright refuse) to do collaborative work where there are multiple people working on the same code and data.
Once we take the collaborative aspect out, and we see data analysts who never had to check out someone else's work to apply minor changes or have someone else apply minor changes to their own code, then we get to the same naive criticism directed at basic organizational practices and tools as we see here.
>The only friction I see with data analysis roles is that data analysts typically don't need (or even outright refuse) to do collaborative work where there are multiple people working on the same code and data.
In your experience, what do you attribute this to?
One way to look at it is that programmers tend to see notebooks as code, and think it makes sense to use the tooling used for code.
Another way to look at it is as a document, and build around that.
Would fiction writers benefit from learning Git ? Sure. Could it be more productive to reduce the activation energy to accomplish the job of tracking changes with another implementation ? I think yes. There are more writers who use Google Docs than there are who use Git.
For example, we added collaborative editing on notebooks[0]. Multiple people can work simultaneously on the same notebook, see each other cursors and changes live. It's a much better experience. We also added multiple checkpoints behind the scenes[1].
I believe that as programmers, we have the opportunity to create better abstractions around workflows to simplify what we take for granted and do as second nature for others.
One issue is cognitive load. People having to remember to do things. We strive to make it automatic. One example is for experiment tracking: sure, they 'just' have to track experiments and add the necessary code, but we do it automatically so it happens without them remembering. Models are detected are saved, parameters and metrics are logged, etc. This considerably reduces the barrier to entry as even a beginner who knows nothing about tracking gets their experiments tracked.
This is what we're doing. Handle complexity on behalf of a user, and reduce the skills required to get things right. Same for deployment. Can they learn Docker? Sure. Why do they have to, though. So we automatically build model images for them, and they can deploy them themselves clicking a button. As I said, these are problems we've had in the past, for example a 'data scientist' having to sollicit the help of à colleague to deploy their model. This was a bottleneck for us.
Sarcasm aside, I've worked with people who fulfil at least any 2 of these behaviours, often-times most of them.
Choice excerpts:
* co-ordinating code between team members by having everyone periodically copy their code to one team members personal google drive, where one of them would then spend a day fixing merge conflicts by hand. When asked why they were doing it like that, would they like any help, git can probably solve these problems, they asserted that this worked fine with them.
* Spinning up machines in EC2, then keeping track of keys (new one for every machine obviously) by storing the Pem files in an S3 bucket when they remembered. This didn't happen, so instead we had a dozen machines nobody could get into anymore after they left...
* Calling Python code in another file, by running os.spawn, calling a python interpreter with the given file, passing in parameters a cmd line arguments, and getting the result by waiting for a specifically named file to be written to disk. When asked "why are you doing this?" I was told "because it was easier".
* All the python they wrote eschewed functions were possible, with everything at root-indentation & no import guards (so it couldn't be imported safely). Functions, when they were used relied heavily on global variables and other objects/imports/etc being present implicitly. There were also logging and json serialisation functions that were hand written. When I asked why this teammate did this they replied "it only took me a couple of minutes and it works? What's wrong?" Unsurprisingly, it didn't serialised datetime objects correctly...
* Re-inventing the functionality offered by Pythons multiprocessing/ Joblib libraries-but worse- by shelling out (again) and manually calling a shell script to detect the number of CPU's and then using x-args to spawn the python processes. "Well we've written it now and it works but maybe next time". Unsurprisingly, these processes would fail, silently and lose data.
* Using eval() in production code because they "couldn't figure out a better way of getting the value of the attribute" despite being told that getattr is safer and faster.
* Maintaining a spark cluster full of Jupiter notebooks unhelpfully named things like STEP_301.ipynb, STEP_405.ipynb and not anything that told you _what_ they did. Figuring out which notebooks called which other notebooks and where any bit of code came from was, unsurprisingly literally kafkaesque. These eventually got checked into git (root credentials, embedded images and all), in a single commit with the message "add to repo".
* Instead of reading the documentation, or using something like SqlAlchemy, code samples of how to connect to various different types of database (mysql, Postgres etc) were stored in a random google doc (once again, one of their personal accounts) and access was passed around.
If I had to deal with engineers with stubborn behaviors like this on a day to day basis, I would go completely insane and quit my job. I can feel the release of cortisol just from reading these bullet points.
I do find this mildly amusing – and sad – as git is possibly one of the worst SCMs for non-programmers because its command set is so bottom-up, and therefore doesn't align with a naive mental model of how version control should work, while at the same time it exposes an interface that makes it all to easy to screw things up catastrophically.
GUI tools only help with that to some extent, too, and only the right ones.
I came from a chemE background and it wasn't even any computational heavy branch of it. Now I do data science in a different field. I feel like command line Git is fantastic and simple 95% of the time and much prefer it over GUIs. Is git really that hard?
Although I really dislike GUIs in general so maybe that's it.
The way the staging area interacts with other commands is completely nonsensical (example: stash and then unstash, and you'll find you've changed which parts of your diff were staged). The commands are horrendously inconsistent and non-orthogonal: git checkout does zillions of different things, git remote needs -v to do anything useful, using "-" to refer to the previous branch works for some commands but not others...
Oh, I've had the joy of working with Perforce, Jazz / Team Concert, etc. /s
Git is widest adopted, period (EDIT: because of how it blossomed out of linux dev, essentially). I was able to stick to bzr or fossil for a lot of things until github and gitlab basically became where open source work (and even corporate transitioned to some extent!) needed to happen, and the friction of using anything else is just too great at this point in time.
Which is a shame, really, as --fast-import/export is actually not a bad way to transition from one scm to another these days, and I'd personally welcome a little more active competition in the space to evolve beyond the current status quo.
> (...) as git is possibly one of the worst SCMs for non-programmers because its command set is so bottom-up,
In your personal opinion, what's so "bottom up" about checking out code from a repository and committing changes to a branch?
> (...) while at the same time it exposes an interface that makes it all to easy to screw things up catastrophically.
What? Care to point out a single example of what you perceive as being one of those "catastrophical" failures?
In all my professional life, which includes a bunch of years as a data analysis, I never experienced a single failure with git. Not a single one.
In fact, the only failure I ever experienced with git came from a stupid error I once made by tracking a git repository which found its way into a Dropbox shared folder.
Care to shed some light on what you perceive as being your pain points?
Fundamentally it is a same as git: you can push, pull, you have commits, branches, merges, etc... and branching is easy.
It is mostly a difference in philosophy. While git will leave you with lots of powerful and flexible tools, Mercurial will be much more limited out of the box, advanced features are extensions you have to enable.
The Mercurial history is also considered sacred, and everything is done do discourage you from modifying it, commands like squash and rebase are hidden behind extensions, branches are also permanently attached to commits (the equivalent of git branches exist and are called bookmarks).
There is also no staging area. Instead of "remote" branches, there is a simpler "phase" system that tell you which commits are local and which one have been pushed.
All that makes Mercurial easier to use, especially for non-developers. And in fact, most people who tried both preferred it over git, with the exception of git experts, who prefer git for its speed and flexibility.
I stopped reading the post once I got to the drawing of the waterfall diagram. There's not a single service I'm aware of that runs today on a waterfall process.
Not sure how you can trust anything else in the post with that obvious of a strawman argument. I'm not going to spend the time trying.
Pick a discipline, and you will find a bunch of people who can tell you why the conventional wisdom doesn't apply to them.
It's more common in the young, but also has a much better prognosis.
In particular I've seen my share of code written by non-developers, and they all make the same classes of mistakes one makes when you have less than a couple thousand hours of focused development work under your belt. Well we can't do that because X, or we don't need that because Y. Oh, okay. Is that why I have to come tow you out of the proverbial mud every couple of months?
Could you humor me and try a few of these things out? I think it'll help.
What people fear most is automated systems that are constructed on wishful thinking, not healthy skepticism. A lot of our processes are about proving to ourselves what we think we already know. There is plenty of code under the AI umbrella for which very conventional unit tests could be written. If you can't use our practices for ML, you'd better drop what you're doing and start developing parity, instead of bullshitting yourselves and everyone else about your exceptionalism.
Code that makes decisions for or about people needs more ceremony and sobriety around it, not less. If you can't do at least as well as a startup (which is a pretty low bar), then we are really in some deep doodoo. But not to worry. The good news is that when the machines take over and we have to hide underground, you'll be the first ones we eat, so you won't suffer long.
I think the issue here is where you put the ceremony.
If you're iterating on your approach to a model, it really is a drag to do a bunch of bullshit in order to run an experiment that's likely to fail and just be thrown out anyways.
If you're shipping that model to production and affecting people's lives, it should really be held to a different standard than the "fuck around and see what happens" experiments.
And this is before we even get into unexplainability of deep neural nets.
Except we have that in software, we call it “hacking” and thirty years on some of us still act surprised when the business people try to ship the proof of concept.
Stop behaving like you can fake it and then make it later. The code has already shipped and they’re pressuring you to move on to the next problem. Anything you haven’t nailed down by the time the customer is happy is not going to get nailed down. The time you get is the time it takes. So if you genuinely haven’t gotten enough time, then you need to slow down and take the time now, because there is no after.
There’s only been two times my code could kill someone, and you bet your ass I didn’t deliver it a moment faster than I thought reasonable, and in one of those cases it ended up being fast enough (the other was, in retrospect, already doomed before I got there)
> If you're iterating on your approach to a model, it really is a drag to do a bunch of bullshit in order to run an experiment that's likely to fail and just be thrown out anyways.
Professional software development has plenty of proofs of concept and "iterating on an approach to a" something. I don't understand what confused state of mind leads anyone to assume that any field of engineering, specially software development, doesn't deal with one off quick and dirty tests.
What really boggles the mind is that any data analyst worth his salt knows very well that he needs to track his inputs to be able to analyse the outputs, thus software development practices are far more forgiving than data analysis ones.
It seems to me that the author just wants to make excuses for shoddy work.
Or that any field of engineering doesn't have a long list of things that 'are a drag'. I've had no end of people tell me, when The Drag is getting to me, that this is part of why we are paid so well.
I don't necessarily agree, I think it's more to do with market value of output, but a large number of people feel that way. Where we do always agree is that there are Things Which Must Be Done, even when you don't wanna.
I have scars from the battles that the author describes and I don't recognize the author as a fellow veteran.
The main problem is that "data scientists" don't follow procedures at all in their work. If they applied conventional software engineering so far as it applies they would do a lot better.(e.g. use version controls but don't check the database password in, think carefully what configuration goes with the hardware, the "model" in general, a particular instance of the "model", etc.)
ML projects get you in trouble in other areas.
For one thing, an ML project might involve a step that takes 24 hours or more to train a model. This means you have to schedule in terms of calendar time (e.g. can't start task A until task B is complete) as opposed to punch clock time, story points, or whatever passes for reality in your flavor of agile.
Related to that is automated testing. Normal software "works or doesn't work" but ML software is expected to get it wrong a certain fraction of the time so the question of "Is version x.y.z good to ship?" is fundamentally different in nature with ordinary software.
It irks me particularly that he ends his circle with "harvest insights" when any real game theorist knows it is about taking actions based on information -- e.g. why winners at gambling and trading use the Kelly Criterion.
A simple google search will surface the author's linkedin profile, where one can see he's been around for more or less 6 years. This makes the entire article even more worrying.
Most high reliability software is still waterfall. It's usually not service-delivered software since people who need high reliability software need it to run locally.
This is a nitpick on "... not a single ..." claim by GP.
GP is otherwise right. First figure in the article is a joke. And that makes the article a joke.
Plenty of waterfalls out there. Even more non-waterfalls, aware of iterative, modern process, who will kick you out of the discussion if you try to sell them waterfall.
ML processes need innovation over those of traditional s/w dev. This article is the worst place on the internet to look for that innovation.
The circular chart example given for Machine Learning is virtually identical to a cycle of continuous improvement in a service or manufacturing operation, except for one little detail,
with Continuous Improvement you don't want the minimum viable product, you want the Maximum Viable Product.
Seems like a machine learning outfit would really benefit from a leader who is smarter to begin with, a better learner, and already more skilled in the task that you want the machine to do.
What are you talking about? I followed that exact process this week in the process of writing and checking in code, as did nearly every other programmer.
I've seen such of the worst throwaway academic garbage code in ML. Maybe the problem is that they completely ignore and look down on software engineering to begin with.
The high concept people never appreciate the grief they're causing for the people who have to implement their vision.
The stuff Frank Lloyd Wright didn't know about construction could fill an entire tour. Which I discovered by taking that tour. Boy, did that dude try to ignore physics.
It's common across all academia i.e. no engineering textbook is complete without 20 pages of raw, uncommented, single-letter variable-ed MATLAB vomited before the index.
I despise python, but MATLAB is positively satanic by comparison (from a software quality perspective at least)
I work at an old school industry with data scientists who use Python, sklearn etc. everyday. Waterfall is everything here. Software is not just at software companies.
Machine learning offers a fantastically powerful toolkit for building useful complex prediction systems quickly. This paper argues it is dangerous to think of these quick wins as coming for free. Using the software engineering framework
of technical debt, we find it is common to incur massive ongoing maintenance costs in real-world ML systems. We explore several ML-specific risk factors to account for in system design. These include boundary erosion, entanglement,
hidden feedback loops, undeclared consumers, data dependencies, configuration issues, changes in the external world, and a variety of system-level anti-patterns.
As many in the comments have pointed out about the actual situation, the two process models in the figure need to be swapped (better yet: replace ML model with the words "no rhyme or reason ad-hoc BS").
As it stands, ML, data-science, computational-science, acadamics are the worst offenders when it comes to following a sane s/w engineering model for whatever they're doing. (for crying out loud, some even refuse to use anything other than FORTRAN-77 ... !!!)
Every ML, data-science, academic team needs to hire at least one traditional s/w engineer experienced in proper modern s/w development.
And they need to take that person seriously instead of being jackasses thinking they have the PhD degrees, or are PhD candidates, and that person doesn't.
This post argues that ML is experimental in nature which makes it harder to plan for. That’s true of any R&D project though! Academia is typically not run on kanban boards, for example.
It's a fallacy to believe that there is a bright line distinction though, and that no engineering practices or tools will improve your research productivity. Traditionally e.g. academic labs traditionally eschew all such approaches not because they wouldn't benefit, but because they don't understand what they are missing and have little incentive to learn, and few opportunities for it.
Most processes have benefit proportional to the number of participants. As an individual little process is required, and spending time maintaining the process is extraneous overhead. Academics tend to want maximal freedom ( in exchange for minimal compensation ) and adding process that constrains their work is unlikely to be productive.
Most ML projects in industry are leveraging understood techniques in novel ways to build real customer facing products within reasonable investment timelines. To say that one can't provide any scope or estimates on these seems weak.
Fair point, but it's not so clear cut. A lot of process is about effective communication over largish groups and/or over largish times. Neither of these really apply in academic research work most of the time.
On the other hand, there are practices that can save you a ton of time even if you are working alone. In an academic setting this can often mean you just learn the ineffectual techniques of whomever came before you. In this case a small amount of education and change of practice (i.e. process) absolutely can dramatically improve overall lab productiveness. Industry isn't immune at all - especially when treating your "R&D" group quite separately from your "production engineering".
Another thing to remember is that there is no such thing as no process; you have one even if you don't understand it. It can be lightweight and almost invariably you can improve it (thought that's not always worth the time spent)
Most of the data science / ML code I've seen reminds me of academic researcher code. Hack and experiment until it kinda works, never write tests because what's the point, it works on my machine and that's good enough.
For a ML-heavy project I ended up being the "productionize this stuff" guy. My favorite was a bunch of python code that depended on a library that under the hood would spin up a new JVM instance to do some NLP work every time it was called (or whatever incorrect way they were using it caused this to happen). And they wanted to do this in the context of a synchronous HTTP request/response cycle.
My overall impression was that these were incredibly smart people, but they had no interest in understanding the context in which their code was going to run, or in understanding business requirements around reliability or maintainability. They just wanted to hack on cool projects that they found interesting.
Given that, it doesn't really surprise me that a lot of ML/data science people don't "get" accepted software development processes. There were some who made the leap and learned to understand why some of these practices are useful and tend to give you a better product, but they seem to unfortunately be in the minority. This is a pretty young field/subfield, and I think it's to be expected that practices are pretty raw and underdeveloped.
The lead-graphic misrepresents software development processes, the machine learning process is just an agile process which as a "software engineering process" directly counters the article's title, it clearly does work for machine learning.
Yes, a quick Google search for Agile Vs Waterfall yields a comparison that looks exactly the same, so indeed Agile processes do work with Machine Learning (at least at a high level). Nothing really novel here, except "waterfall doesn't work for ML".
Because software totally doesn't require prototyping, experimentation and measuring of intermediate progress. /s
Dealing with data teams that just won't learn reasonable software engineering practices but still want to run software in production is incredibly painful. Eventually you just have to sit down with them and lay down the ground rules on what is and isn't acceptable.
Once they get over the initial stage of complaining they eventually convert and can't understand why they ever did it wrong in the first place... just like junior software engineers.
The snowflake part where they feel they are somehow different and entitled to use poor processes and force poor tools and ecosystems on everyone else though really does irk me.
Yes your field is quickly expanding, yes your salary is probably over-inflated vs your competence and experience but that doesn't make you special.
It's sad to see such "to hell with it" naivete (and the comments here with broad supporting evidence that data scientists are poor software developers.
There are also a lot of DS people wrestling with the deeper challenges at the heart of MLOps and beyond just advocating sane team-based workflows, are looking at ways to harden and structure ML specific processes in the planning, design, build, and deploy phases.
Test coverage of ML models and a good discussion on why and how ML code testing isn't the same as traditional testing - https://www.jeremyjordan.me/testing-ml/
And of course a whole suite of tools and research beingn done on data, pipeline, and model management, optimizing deployment and serving, explainability and interpretability, all in the service of applying enterprise-ready, engineering-grade rigor to data science.
And then you read something like this and want to tear your hair out.
The nicest possible explanation is that this article is an excellent piece of sarcasm.
The very first thing in the article is a comparison of Waterfall and Agile but it is labelled "Software Engineering" and "Machine Learning"?!
Like, I am so confused. Is the implication that AI researches invented Agile or something? Literally everybody does (or pretends to do) some kind of Agile these days. And I don't mean this in a "my enlightened startup does software dev like this" way, big corporations have the actual job title SCRUM master for years now. I did mom-and-pop store Wordpress projects with "machine learning methods" apparently - nice!
After wording this out I brought myself to read the whole article, and, well, it is a marketing piece for their productivity tool Comet which solves all the problem you have by building AI, which does not have "The provable correctness of software engineering" (I wish software would be provably correct :| ).
I've found the same to be true of any sort of creative engineering project. It's common to have an ill-defined end goal "must be cool" or "is it art?" which is just inherently subjective.
I often see comparisons of traditional software engineering vs machine learning like this where the former is a linear sequence of stages without cycles and the latter is some kind of tight iterative loop.
But my work in both building backend services and building machine learning models has always looked like how the author describes machine learning models.
In my experience the "process" generally isn't that different; but the cycle times are long enough for machine learning that it can feel different.
The fundamental difference in ML of you work with data, where as in s/w you work with rules.
It's a subtle difference but I believe is very profound. It's very hard to develop intuition around data and most s/w devs treat data as rules.
It's not entirely the fault is DS folks who happen to come from non s/w background and vice-versa.
In my mind the management should understand that their is a gap and seek to help close the same.
People I work with don't care that our notebook tools have rudimentary syntax highlighting or type-checking. We don't rely on our tools to make sure our code is written correctly. We just memorize the APIs and rely on experimentation to get things working.
Please don't make us use git. Checking out and checking in files is too slow! Oftentimes, Slacking code to a colleague is the best way to collaborate, and the fastest.
Don't make us use confusing and broken authentication schemes to access our data! I work best if I can just download live data to my machine and work locally. If it's too big or it's something like streaming, just give me an admin password that I can save in my notebook and use to hit some database clusters. Nothing wrong with that!