https://www.hillelwayne.com/tags/engineering/ Recent content in Engineering on Hillel Wayne Hugo -- gohugo.io en-us Mon, 15 Jul 2019 00:00:00 +0000 https://www.hillelwayne.com/requirements/ Mon, 15 Jul 2019 00:00:00 +0000 https://www.hillelwayne.com/requirements/ Many bugs are implementation errors: there is a mistake in the code that makes it not do what you wanted it to do. For example, you may have accidentally left out the “list is empty” case, or written a nonterminating function. You can identify it as “definitely wrong” for a given input. Most testing, in fact most writing on software correctness, deals primarily with implementation errors. Above that we have specification errors. https://www.hillelwayne.com/post/reasoning-about-systems/ Tue, 13 Feb 2018 00:00:00 +0000 https://www.hillelwayne.com/post/reasoning-about-systems/ In programming arguments, such as static vs dynamic typing,1 people use their experiences and reason to frame these debates. However, reason is often a poor grounding for justifying complex positions. Usually warnings against using “reason” take the form of “it’s easy to be biased” or “we tend to make logical fallacies.” But this presupposes that if we were less biased we could answer the question by thinking really hard. I’d like to argue that this is actually impossible: we can’t understand something “static vs dynamic” with reason alone. https://www.hillelwayne.com/post/the-best-se-paper/ Fri, 12 Jan 2018 00:00:00 +0000 https://www.hillelwayne.com/post/the-best-se-paper/ I want to call attention to one of the best papers I’ve ever read on software engineering, ever. Ready to be dazzled? Here goes: Fixing Faults in C and Java Source Code: Abbreviated vs. Full-Word Identifier Names (preprint) I know, right? Sheer brilliance. Okay, maybe it doesn’t have the most exciting subject matter, but I think everybody should read it. Here’s why: Manageable scope. “Is clean code good?” Too broad, what is ‘clean code’ and what is ‘good’? https://www.hillelwayne.com/post/right-tool/ Sun, 10 Dec 2017 00:00:00 +0000 https://www.hillelwayne.com/post/right-tool/ “Use the right tool for the job” is a pretty tired cliche. Mostly it’s used to dismiss overengineering and one-size-fits-all solutions to problems, like using microservices for your 10-user app. It isn’t a bad saying, it’s just tautologically true. I don’t think anybody wants to use the wrong tool for the job, unless they’re trying to sabotage it. “Should I use the right tool for the job?” is a rhetorical question. https://www.hillelwayne.com/post/contracts/ Mon, 27 Nov 2017 00:00:00 +0000 https://www.hillelwayne.com/post/contracts/ I’ve namedropped contracts enough here that I think it’s finally time to go talk about them. A lot of people conflate them with class interfaces / dynamic typing / “your unit tests are your contract”, which muddies the discussion and makes it hard to show their benefits. So I’d like to build up the idea of contracts from first principles. We’re going to work in Python, up until the point where things get crazy. https://www.hillelwayne.com/post/why-tdd-isnt-crap/ Mon, 30 Oct 2017 00:00:00 +0000 https://www.hillelwayne.com/post/why-tdd-isnt-crap/ After my recent vitriol about unit testing, a couple of people sent me Why TDD is Crap as a thorough debunking of TDD and unit testing. As someone very interested in software correctness, I ended up writing a debunking of his debunking. Transcriptions will be in quotes, my responses below. Some important notes: From what can tell, neither of us is using TDD in the “purest” possible sense of “write the bare minimum that makes the smallest unit test pass”. https://www.hillelwayne.com/post/unit-tests-are-not-tests/ Thu, 26 Oct 2017 00:00:00 +0000 https://www.hillelwayne.com/post/unit-tests-are-not-tests/ This is an absolutely insane idea and I’m delighted by its audacity so I’m sharing it with all y’all. There’s like a bazillion things wrong with it but saying dumb shit has never stopped me before so let’s do some grambling! The way I see it, unit tests act as a frame around your coding. The most common practice is you write the tests to cover the return values and calls, write your code, and enforce that it passes the unit tests.