TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Consultants Ate My Unit Tests

128 点作者 dragthor大约 9 年前

19 条评论

jasonkester大约 9 年前
Ah, the sadness of seeing your code again after somebody else has had it for a couple years. I feel the author&#x27;s pain.<p>I had a company license the source code from one of my old projects to use as the basis for a new site they were building. I built out the bits they needed on a consulting basis and got them launched. Then they started thinking about how expensive I was, and how much they would save if they moved the development overseas.<p>Fair enough. My philosophy on such matters is that it&#x27;s best to let a client learn this lesson through painful experience. All the best, guys.<p>They made it about a year before the site stopped working completely. Reading this article reminded me of the first time I opened the source that came back. You just wouldn&#x27;t believe that you could do that much damage in such a short time.<p>I quoted them double my old bill rate and got them back up and running, with all the new functionality they had been wanting, and re-launched. They brought in a new guy to run things, and he started making comments about expenses, and how surely there must be a way to do this cheaper. He even found a local kid who knew some C# and would be willing to help out for a lot less than I was billing.<p>No problem. All the best.<p>I took a quick look at the codebase when they got back in touch a few months later and politely declined to come back on board.
评论 #11363769 未加载
评论 #11363713 未加载
评论 #11365565 未加载
评论 #11365161 未加载
taylodl大约 9 年前
I&#x27;ve seen this with my own two eyes. When asked why they removed the unit test they said after they made some rather extensive code changes the tests were failing so they deleted them. Nor was there any trace of irony in their response. When asked didn&#x27;t they realize that was the whole point of having unit tests they replied that they knew, but they had deadlines to meet and there wasn&#x27;t enough time. Since controls had been put in place to not ship with failing unit tests but not to check for test coverage they took the easy way out and deleted the tests. I informed management what they had done and thankfully they were relieved of their contract and their consulting company was informed what they had done. I don&#x27;t know what happened to them after that.<p>Thing is, once the PM was informed what they had done we did a couple of sprints where we restored the unit tests (which we still had in our history) and got them passing. They had no idea the consultants were doing such shoddy work in order to meet deadlines. The upside of all this is to this day that PM now actively checks the Jenkins dashboard to see the current state of tests and that no tests have been deleted - and that&#x27;s for all his projects not just that one particular projects. Now that the story is part of our IT lore the new consultants get the message loud and clear we&#x27;re not afraid to send them packing.<p>In the end this turned out to be a good story for us - but wow.
评论 #11363852 未加载
评论 #11363249 未加载
评论 #11365281 未加载
评论 #11363670 未加载
joeld42大约 9 年前
I don&#x27;t agree with the implicit premise that if the cheaper consultants had been required to maintain the tests and provide coverage for what they wrote, the code quality would have stayed high. In my experience, it would have turned into just as much of a mess, except would have taken three times as much work to maintain all the tests in the process.<p>Maybe the tests would have had some benefits, but would they have enough to justify all the extra time to write&#x2F;maintain them? Certainly not.<p>In my experience, good programmers write good code, tests or not, and bad programmers write bad code, tests or not. I&#x27;m not against testing altogether, it makes sense in some contexts (like very widely used libraries). It&#x27;s also useful for beginners who aren&#x27;t sure &quot;where to start&quot; with a project. But even in cases where people swear that their tests are invaluable because it&#x27;s tricky code that breaks often, that&#x27;s a sign to me that that code needs to be made less fragile, not more well tested. TDD is a cargo cult.
评论 #11363405 未加载
评论 #11364175 未加载
评论 #11363764 未加载
评论 #11363417 未加载
评论 #11363935 未加载
knappe大约 9 年前
I&#x27;ve been on the other side of this as a consultant. I once was consulting for a place where I asked if I could run the existing tests to confirm I hadn&#x27;t broken anything when adding in some new functionality. The owner of the project yelled (actually, really yelled) at me to never run the tests, ever. Apparently they deleted production data.<p>I didn&#x27;t spend much time consulting for them.
评论 #11363395 未加载
评论 #11363436 未加载
评论 #11363244 未加载
评论 #11364811 未加载
评论 #11366013 未加载
chvid大约 9 年前
Some of the reasons why I delete unit tests from time to time:<p>- Often the quality of unit test code is a lot worse than the production code.<p>- Some times people test too much in a single test (ie. more than one unit) making it very hard to change the design of the application.<p>- Some times a unit test misunderstands how the application is supposed to work or the requirements change.<p>- Some times a unit test tests something too little or too trivial.<p>- Some other test is already covering the case.<p>I personally don&#x27;t weight 100% test coverage as critical. Often other aspects of QA in application development are more important (i.e. integration test or documentation).
评论 #11364852 未加载
alexc05大约 9 年前
I, very recently, began writing a suite of tests to go along-side a complex mobile app. During a stand-up meeting I (somewhat) proudly announced that for a particularly onerous piece of business logic, I had 100% coverage with tests that run in less than a second.<p>The project manager in the room was worried about the time it was going to take. All the developers in the room piped up to say &quot;oh, no, this actually saves time&quot;<p>The next day, I found myself in a private meeting room with the project manager and my line manager.<p>Both were trying to tell me that unit tests are not part of the scope of the project, not were they approved and, that I was to stop writing them.<p>Manual QA was the way to go at the end of the project.<p>Yesterday, I was in the office from 10am to 2am on a national holiday addressing issues arising from QA.<p>It was unproductive to spend the day wondering how many of those defects I&#x27;d have been able to catch months ago if I&#x27;d been writing tests all along.<p>When you&#x27;re the only one on your team who respects the tests, the world feels like a very bleak place.
评论 #11365592 未加载
评论 #11368267 未加载
cognivore大约 9 年前
I&#x27;m going to be a contrarian here and say that if unit tests, in most cases, made economic sense they&#x27;d be a given in almost all software development.<p>But they&#x27;re not. Do we assume business owners are dumb? Do we assume managers are dumb? That&#x27;s a popular position for technical people. &quot;Oh, you just don&#x27;t understand how valuable those unit tests are!&quot;<p>But the cost of maintaining unit test vs. the cost of fixing bugs later might favor just fixing the bugs later. Maybe it doesn&#x27;t sometimes - but one is an upfront cost you know about, and one is a nebulous cost that you might or might not have to pay later.<p>Given that, I know what most people paying the bills are going to choose.
评论 #11366899 未加载
评论 #11365034 未加载
评论 #11365260 未加载
Gratsby大约 9 年前
I had a different experience with tests. 18 years ago at one company I laid out a test plan. Some of it was automated, the majority of it was manual. It applied specifically to a large custom built application.<p>2 years ago, I was at an entirely different company. They handed me their test plan documentation. Lo and behold, it was my document, now laden with another consulting company&#x27;s logo. It was missing a few tests, but there was nothing new.<p>I was angry for a solid 4 hours. Then I had to laugh about it. I would be flattered that my 18 year old work was still being used, but it was quite simply dated. If a big company was being cheap and getting things built by offshore resources who had no better way to accomplish it than by stealing my work, then they got what they deserved.
astockwell大约 9 年前
I have this same underlying feeling every place I work. Maybe it&#x27;s because I&#x27;m not in the Valley, but in the last several jobs I&#x27;ve had, I was the only person advocating for things like unit tests, release pipelines, or even VCS(!). And each time I get a new job, team members and bosses from the old one inevitably call with similar self-inflicted crisis like this.
评论 #11364061 未加载
评论 #11364086 未加载
vinceguidry大约 9 年前
Man, this makes me sad. Not about the atrophied codebase, but about the inevitably extreme difficulty of keeping one properly maintained.<p>Expertise in software maintenance isn&#x27;t common and it isn&#x27;t cheap. Every greenfield dev is going to eventually see his project handed off to people who won&#x27;t understand or respect his conventions and methods. That mostly destroys it, but business requirements can put it on chemo and a food tube and keep it alive against its will for a long, long time, and it&#x27;s not a pretty sight.<p>It&#x27;s practically impossible to. I&#x27;ve been maintaining an ancient Rails codebase for the last two and a half years. I&#x27;m perhaps the fourth or fifth such guy to do so since it was built. The project was never updated past a certain point release and it&#x27;s more work than it would be economical to do to do that now. I&#x27;m experienced enough now to take it on, but both me and the company have better things to do with our time and resources.<p>It is so ridiculously easy to make a bad decision that seems like a good decision that instead ultimately dooms the project. Software is like this weird life-form from another part of the galaxy whose motives are so alien to us that we can&#x27;t even begin to come to grips with it. We know it&#x27;s not actively plotting against us, well, pretty sure, but more than that? All you can do is shrug your shoulders and hope it doesn&#x27;t consider you a threat today.
bunderbunder大约 9 年前
I don&#x27;t think this should be surprising to anyone.<p>Outside developers don&#x27;t have any real ownership of their work product. Even if they know better in principle (and many do), they don&#x27;t have any incentive to practice good stewardship. And bargain-basement outside developers aren&#x27;t magical productivity pixies; the reason they are able to charge lower prices because they don&#x27;t need to charge you for all the things they aren&#x27;t taking the time to do.
ErikAugust大约 9 年前
Moral of the story: Great developers are profit centers, bad developers are cost centers.<p>Unfortunately, many execs without development experience neglect to see it this way.<p>They see &quot;expensive cost center&quot; that can easily replaced with cheaper labor. Cool thing is, as others (like the author) have said, they tend to get burned and end up re-hiring you on even better-than-original terms.<p>Kudos to the author for doing good work!
daxfohl大约 9 年前
FWIW I&#x27;ve been eating my own unit tests these days. I find they slow me down and distract me from what I&#x27;m doing.<p>You&#x27;ve got the &quot;large scope&quot; unit tests that test functions that take lots of dependencies, via mocking. These often end up being so mocked, that you&#x27;re testing the mocks more than the function itself. You feel smart when you write it, but a week afterwards you can&#x27;t even remember what it&#x27;s testing.<p>You&#x27;ve got the &quot;small scope&quot; tests that test small pure logic functions. Great, but these hardly ever change. It doesn&#x27;t seem worth the overhead to maintain a test for unchanging code.<p>There&#x27;s a &quot;fuzzy middle&quot; that <i>could</i> be reasonably worth unit testing, but these are the functions that are most likely to get completely ripped up during refactoring and new feature dev.<p>To me, a sound architecture (no global variables, a minimum of mutation[1], etc) and a sound type system means things generally work the first time anyway, without the need to maintain a big honking test suite and everything required to run it.<p>I&#x27;m finding it&#x27;s much quicker to get things out the door without this overhead, the architecture ends up being simpler (<i>far</i> simpler in some cases) because I don&#x27;t have to put test hooks in for everything, I can refactor without the worry of how many unit tests will break, and I&#x27;ve experienced no downturn in quality.<p>Of course there are cases (public core libraries, large distributed dev teams, really complex pure logic) where unit tests are absolutely necessary, but for <i>most</i> of my projects these days I&#x27;m finding them to be redundant.<p>[1] In fact, one could argue that the greatest benefit from the TDD phase was that TDD is harder with globals and mutation, so it reduced incidences thereof.
stcredzero大约 9 年前
<i>maybe the more disorganized the code, the more “less expensive” consultant work there is to do (charge)?</i><p>I know of one consulting shop that had a dependable stream of income from a major European bank, because that bank had a project that didn&#x27;t use source control, so they got to be the periodic hero and get paid for it.
scotty79大约 9 年前
That&#x27;s normal. Any non-essential complexity gets dropped. Accidental complexity accumulates.<p>In one project next developer ate my build script. Why bother with compiling less to css if you can just edit css and forget the less files and build script. Same went for r.js bundler.<p>In other project I participated angular got dropped because people couldn&#x27;t be bothered with it.
rsyring大约 9 年前
The bulk of the first comment of the article was as good as the article IMO. Quoting here:<p>&gt;&gt; But maybe the more disorganized the code, the more “less expensive” consultant work there is to do (charge)?<p>&gt; This is implying maybe they intentionally disorganize the code so they&#x27;ll get more billable hours?<p>&gt; I seriously seriously doubt it.<p>&gt; Rather, it&#x27;s as simple as: If you want to add features or make changes paying the cheapest possible amount, you simply aren&#x27;t paying for well-organized code.<p>&gt; It&#x27;s not just less experienced programmers, it&#x27;s less experienced programmers trying to get you the feature in the least possible hours. They aren&#x27;t doing artificial things to bill you more hours, it&#x27;s in fact quite the reverse -- they really are trying to get the feature done in as few hours as possible, to bill you as few hours as possible.<p>&gt; And when you do that, you simply don&#x27;t have time to organize the code well, or keep the tests working. You&#x27;re shoving it out the door as quick as you can. Of course it takes more time to keep the code well-organized than to just hack it until the feature works as quickly as possible. Of course it takes more time to maintain the tests -- over the short term, and all you ever have is the short term when you&#x27;re paying and getting paid little by little feature by feature.<p>&gt; They have other customers, they don&#x27;t need to bill you artificial hours. They really are billing you as few hours as they possibly can -- because that&#x27;s how they get customers, being the cheapest. That&#x27;s exactly what the client asked for, it to be done as cheaply as possible.<p>&gt; You get what you pay for.<p>I have only recently started working for a consultant that bills hourly. It&#x27;s an eye opener. We are a small shop of experienced developers, we work for people that do want us to produce quality, and we do, we do good work, and we do write tests and maintain our tests. But it is a still a constant struggle inside my head between doing it as right as I really want to, and not charging the client more hours than the feature seems &#x27;worth&#x27;.<p>&gt; If you as a client prioritizes price even higher over quality (and you have no way to judge internal quality anyway, not being a coder, so why wouldn&#x27;t you? It looks nice and works, what else can you judge?), if you&#x27;re hiring less expensive developers to save money... they might be skilled devs in fact, but if you are trying to get it done as cheaply as possible, you are not going to get well-organized code. And you as a client don&#x27;t care, what do you care about well-organized code? Until it reaches a breaking point where your technical debt is so high you can&#x27;t get any more features at all, and you realize, oops... and probably still don&#x27;t understand what you did wrong or could have done differently.<p>&gt; Good software is expensive. Too expensive. More expensive than most people who need good software can afford. Which is why we have so much shitty software.
raulk大约 9 年前
Cheap labor != consultant. In fact, real consultants tend to be expensive. A real consultant is an expert in a field, not an asterisk or wildcard for anything.
revelation大约 9 年前
Of course, then when the OP was asked back for one particular thing, he didn&#x27;t go and setup the unit tests again, either. He did the same exact thing as the consultants.
评论 #11363397 未加载
x3n0ph3n3大约 9 年前
The format of this article was downright annoying.
评论 #11363211 未加载