Law of Demeter, “don’t talk to strangers”, is also easier to remember, in a language that forces you to null-check a lot. It is riskier to talk to your neighbours neighbours if they might have been deallocated. Following the Law of Demeter aims at loosely coupled architecture, and code that is easier to change. Loosely coupled architecture can also be viewed as deliberately coupled architecture. To craft those relationship graphs we can reuse the methods for managing memory.
It is good that not all languages require you to allocate memory by hand. The skills required to design a system that does not leak memory, might have other usages though. Try that the next time you find yourself in a codebase where access to objects are expected to work from all over the place. Code where changing one signature ripples through the entire system.
Questions to ask:
Keeping a tidy object graph helps with memory management, but also with separating concerns and easy to change code.
Interfaces can be used to avoid import loops in patterns like observer-observable. And it also creates an abstraction layer for the design (if done properly).
]]>Unit tests define the collaborators and the purpose of a piece of code. When reading code with unit tests, we can read the tests first, and focus on how the unit interacts with the system. The review of the computational code, like the body of a function, can then focus on the implementation.
Putting this in the framework created by Heander, we solve the conflict between clarity and understanding by separation of concerns. Each test provides context for purpose and interaction for that unit. At that time we are not interested in the implementation, just the interfaces, and can remove that part of the cognitive noise. When we have enough understanding of the purpose of the code we can move to the implementation. That should then be a pretty small unit, with well defined collaborators, that we are already familiar with from the test. We have the external context in place and can focus on implementation details.
Separating concerns like that lightens the cognitive load, and might be a part of solving the conflict between clarity and understanding.
Test driving you code in small units, does not only help with cognitive load in the moment, but also helps everyone that will read that piece of code in the future.
]]>So if the code under test requires a lot of magic to be verified, it will not be straightforward to use in the codebase.
A rule of thumb is to favour testing frameworks that are so simple that you could easily just have written the code yourself. A testing framework is a convenience. It should not make it possible to test things that you could not test before.
When you need to construct the test data, write your test doubles and create every other dependency needed, pure laziness will create code that is modular and easy for others to use. This is the design pressure from the tests.
If you let a framework entangle your code, unit testing gets hard really fast. A Wunderbaum testing framework will mock and stub your controllers and databases, instead of helping you keep the domain logic separate and testable. It removes the design pressure, one of the reasons to write tests first.
Sometimes you end up with a codebase that needs to get under test before it can be fixed. Often that can be done through approval testing or end-to-end testing, just to have some sense of safety. In that process you might also find Wunderbaum testing frameworks helpful, since the code stinks so much you need all the perfume you can get.
But when the code just has some odour, try to avoid things that hide the smell. If your code is hard to test with a slim testing framework, you probably have code that is too interdependent, or not modular enough.
Keep your code nose fresh and think of design pressure as a friend.
]]>The one to first come to mind is often This is wrong!. The other one, easy to miss, is a parallel path of I am missing important information.
Before I know what the case is, I try to act as if the cat is both dead and alive at the same time. Both options are true and false. It keeps the door open for different scenarios, and have respect for the competence in the person receiving feedback.
Take a code review as an example, where I encounter some asynchronicity. that looks like it would cause a race condition.
Lets look at the alternative conversations.
- Race condition, fix it!.
- Oh, thank you for spotting. I knew I had to fix it, but forgot.
- This looks like something that could cause a race condition. Or is there anything I am missing?
- Oh, thank you for spotting. I knew I had to fix it, but forgot.
- Race condition, fix it!.
- This part of the data is immutable now. You must have worked with the other team the week we changed that. Good I got to tell you!
- This looks like something that could cause a race condition. Or is there anything I am missing?
- This part of the data is immutable now. You must have worked with the other team the week we changed that. Good I got to tell you!
The tone shifts a lot depending on how the first sentence is phrased. And the difference is clearest when the reviewer is wrong.
There is a risk of not sounding sincere in the question, then it won’t work. People who are underestimated might seem ignorant rather than humble. That has to be taken into account.
The next time you give feedback, phrase it so that the conversation can flow also when you are wrong.
]]>To test code interacting with the ports, we need test doubles to use as the adapters.
As an example we have pseudo code for a system that sometimes start a siren.
The code actually starting the siren is wrapped in a simple class
implementing the port-protocol Siren.
protocol Siren {
void turnOn()
}
The code starting the siren gets it as a parameter,
together with the boolean emergency.
I really don’t want the siren to go off when there is not an emergency.
So to make sure that the function does not even try to start the siren, we use a Dynamite Double. It is a test double that fails the test if the code tries to call its functions. Touch it and it explodes.
class DynamiteDoubleSiren implements Siren {
void turnOn(){
make.test.fail.horribly
}
}
Instead of using a test double that records if, and how, it has been called, I feel safer if the “no action”-alternative is tested with a dynamite double.
]]>Software development is not always as strict, but the mathematical mindset can help us in writing predictable code.
In Test Driven Development (TDD) we let the tests and the code grow together, creating one failing test at the time and making it pass.
Deliberately deciding what input values are valid for a function is a part of TDD. We then also define the behaviour if the function can be used outside of its definition. (In some languages this is done through the definition of signatures and types.)
TDD is a thinking tool more than a way to write test.
Let it help you define your domain and its boundaries.
]]>The previous post is on coping with IT-stress This is about preventing it.
Software is named in contrast to hardware. Computer programs should be easy to change. You can get an update into production in less then an hour, with modern methods. ( Refer to Accelerate if you encounter someone who says otherwise.) If the software is not working, for the ones using it, the software should be changed.
Half of corporate budgets for software (in Sweden) is used for customisation. Either for modifications of existing software by external parties or external developers working on in-house projects. On top of that, about 40% of IT-workers in Sweden work for companies that produce something else than software.
That is a lot of software being written with a specific customer in mind. If you are that customer, demand to be a part of the entire process. Software tailored to your needs requires your input, just as a suit or dress is made with multiple fittings.
“Off the shelf”-software has to be tried by the end users before committed to. The cognitive ergonomics when investing in software should be considered similar to ergonomics when furnishing a workshop or office.
If the software is a part of your “competitive edge”, consider having a dedicated team of software developers, who get to know you and your domain really well. Provide them with direct access to the end user and put them close to (or in) the product team.
The software team should be like a painters brush, swift in the hands of product development.
If your software team can not deliver on that, provide them with training and other support until they do. Your organisation deserves it.
The purpose of software is to make things better. It is a failure if the end user can not easily use the product. We can check that we are building the right thing as we go, if we have the end user close and work in small steps. In Extreme Programing, a flavour of agile, the customer is represented in the team. If that does not work, find another way to get constant and real feedback. This avoids delivering something that is “done”, but can not be used.
Whenever you can, demand more of software you encounter. Accelerate is a good book on what can be expected of an organisation delivering software. The DevOps report 2021 and The DevOps report 2019 are shorter reports covering the findings from the research. Remember that soft in software is soft as in changeable. If you are in charge of spending money on software, off-the-shelf or in developer hours, take your responsibility. Software development is best done with the end user in focus and in small steps. Don’t accept less.
]]>early-career people should take the time to download and look at the leaked farcry code. not to learn some new technical lessons, but to disabuse themselves of the notion of “clean code”. nicebyte
From reading more of the thread, my interpretation is: “You don’t need good programming practises to make money from software.” That might be true, in some circumstances, but to make it an “early-career”-advice I would like to add some perspective.
First I want to separate internal and external software quality, as described in this post. Internal quality is from a developer perspective, external quality is what the user sees. They can be more or less dependent of each other, but have different effects.
J.B. Rainsberger has a talk on “The economics of software design” (video). There he introduces t0, the point in time where the total cost of having written the code is the same regardless of if we just did it fast and sloppy or slower and intentionally sustainable. We don’t know when t0 will be, but it exists for every project. After t0 you reap the profit from having continuously improved the code since the start. In just implementing features as fast as possible, we bet against the project surviving past t0. We only save money by not caring about “clean code” if the project does not reach t0. The t0 measure is about the value of internal quality.
It is interesting to use a game as an example for when internal quality is unnecessary. Games are one of the few kinds of software still distributed on physical media. I believe that a lot of games change less over time then other software. The cost of a messy codebase come when we want to edit it. Bugfixes in a feature complete codebase can be plastered on, as long as the code do not move.
In my post on useworthiness I talk about how utility and usability mix to decide if software is worth using. If we can not add new features utility will suffer. Usability will be a problem if the internal quality problems show as external quality problems, or slow down improvements in user experience over all.
For games that change more over time, like Pokémon Go, the condition of the codebase matters, and will start to show. Niantic has publicly stated that they have quality problems. In Pokémon Go the problems shows as defects, delayed features and draining of the users resources such as mobile data and battery. All of that results in lower external quality.
The gamble here is both with t0, “will the project die before the codebase does?”, and with the users tolerance for unreliability, in relationship to how the game makes money.
Pokemon Go makes money, but Niantic has still recently laid off 25% of its workforce.
This is why my “early-career” advice is:
Find work where they care about code quality.
It will be better for your mental health as well, but that is for another post.
]]>Internal quality is a codebase where the functionality is easy to change without unexpected side effects.
External quality is software that behave as expected by the user, demanding as little effort as possible.
Sometimes the two are related. Code forced into new purposes without prior refactoring might behave clunky or erratic.
A lack in internal quality can still be prevented from showing to the user. This is where we do endless manual testing, extensive monitoring in operations or add a lot of extra computational resources.
On the other hand, software with high internal quality might still have poor external quality. If the behaviour of the application is hard for the user to navigate and predict, it will still not be perceived as working correctly.
If the software has internal quality it is easier to change. This makes it easier to do user research and update its behaviour, so that it works well for the user.
Internal quality makes it easy to write software that do what we expect. External quality is software that does what the end users expect.
]]>On the other hand, a badly designed, or even unstable, product that provides something really valuable, will be used anyway. (That is, until something better is available, or the pain grows too big.)
Useworthiness is the combination of usability and utility. How well it works is weighted with how valuable the function is. Both impact how the user interacts with your product.
Compare it with food. That something is easy to eat and that it is tasty is two different things. Eating canned corn with a spoon is really easy. Despite that, I prefer to eat it fresh on the cob, including the flossing required afterwards.
If you work with software that provides something really useful, people might be using it despite its level of quality.
If it is something that the user has to do, participation data is even less valuable to decide the quality of your product.
Get feedback from you user, besides recorded data, to separate the usability from the utility and retain customers over time.
If you take pride in producing quality user experience and product stability, make sure you work with something valuable to people, so that it is not wasted.
User research is the best way to get useworthy products.
]]>
- has no side effects.
- always produces the same output for a given input.
Pure functions are known to be easy to test. We can use their characteristics to make all code easier to test.
Even if you don’t write functional code, this is good practise. When separated from the rest you can test the logic to your hearts content, and create a single integration test for the side effects. We need side effects, but keep them isolated and in methods without conditionals.
If everything that might vary is part of the input, the output can be deterministic. In contrast, letting the method have access to collaborators and state “behind the scenes”, creates variance that is independent of the input. That will make for more setup in the tests, and more combinations to cover.
Pure functions remove some of the hardest part from testing, you can use that knowledge in all software development.
]]>There is code like this, frameworks that infiltrate the domain code until they are inseparable. Change one part and it affects all of it. You are never safe to move. Bad habits of the team that designed the framework will seep into the code base. (Regardless if the framework is external or developed alongside the domain logic.) Getting free takes time. Approval tests and safe refactoring are the flamethrowers that can save us.
To avoid this anti-pattern, keep your frameworks at arms length. Isolate code that is framework specific from your domain logic. Use interfaces! Hexagonal design (ports and adapters) can be used for this.
A bonus is that the code will be testable. Frameworks are good at side effects. Let them deal with that. The domain code is then easy to put in unit tests.
If the framework is not working for you, or is updated, make sure the interface is preserved and the change is mostly done. It won’t even make your nose bleed.
]]>We want reusable code. Being easily unit testable is proof that the code can work in two contexts. As soon as you use the unit outside the test, you are already reusing it.
Design pressure from driving development with tests is like the training kids get from play. We teach the code how to interact with others, experiment with interfaces, boundaries and naming.
When we have code that works well in a unit test (and no, if you need a fancy testing framework the code is not behaving well enough ) we can let it play with the rest of the production code.
If it is a pain to test, it will be a pain to use, maintain and debug. So play with the code a bit first, it will be worth it.
]]>Code that has a limited responsibility, with only one stakeholder. Objects and functions that can be part of composition, without being altered. Interactions designed to work even if the implementation details of one actor changes. They will all likely result in code that has not been touched or altered for a very long time. The code is still in use, but as “done” as code ever gets.
It is a blessing when code is allowed to grow stale. We should design our code so that it can slowly sediment, harden by itself, in the peace good design and proper testing creates. The codebase as a whole will still evolve, and that is going fast. Changes to support the business are quickly done in small units with good interfaces. Sometimes a bigger part is swapped out. In other cases, an old trustworthy part is promoted into a library. There is movement where it is needed, but the ripple effects don’t reach far.
When I hear about code freeze or software hardening as part of a delivery pipeline, I think about the aging and maturing of code. With small units of decoupled and well tested code, it will naturally harden. Some files will be created, used for days or decades, and then deleted, without ever being changed. Others will have an eventful youth, but soon settle into being run, but not altered. For me, that is the goal, letting the legacy of code create a solid foundation for new work.
What do you have to change to let your code age in peace?
]]>Not only will anti-work make life harder inside the organisation, it also leaks into the surrounding world. Anti-work pollution!
There is a lot of literature on the topic targeting the IT-industry. The Phoenix Project both describes where it comes from, and parts of what we can do about it. Preventing anti-work is also something a Technical Coach helps with.
We want to minimise anti-work to be more profitable and a better work place. We should also pay attention to what our anti-work does to people outside the company. An organisation that fails to prevent anti-work for its employee, will also cause anti-work for its customer.
It might not be that the entire system is down. It is enough that there is some kind of unavailability or error, that will ask more of the customer than they planned for. Restarting apps or devices. Forms that clear all entries on a single error. Data that don’t sync properly. Having to wait or reschedule your task for another time. And it is not only software that manifests it, though it is often software involved. (Or better software could have prevented it.)
Ordered food that only partly show up might not seem like a biggie, but it might also cause the anti-work that blows up something really important for that individual at that time.
When the anti-work hits your life, instead of your work, we often lack protective systems. The nuclear-family team of two, or one, doesn’t have the redundancy of an IT-department. If the service you build is of any use, or importance at all, it hurts when it fails the user. It might only be a paper cut, but could be one of thousands in total. It will probably hit harder for people with less privilege to start with. As a system, a society, we should all be more careful with each others time and energy.
Don’t be an anti-work polluter! Take care to build quality software!
]]>There is a proverb present in many languages.
Many chefs spoil the soup.
In German there is a version:
Many chefs spoil the porridge, by adding too much salt.
(It sounds much better in German.)
I like the German version since it is specific on how the porridge is ruined. Each chef has their own plan, adding their own salt, and the porridge can’t take it. That is what happens with code as well. The single responsibility principle is about that.
Code should have only one responsibility, so that there is only one chef who might put salt in it. If a piece of code has more than one stakeholder, chef, too much stuff, salt, will be added to the code.
So what is a chef/stakeholder in this case?
Stakeholders are people, or organisations, who want to change how the code works.
It can be an external API that is used, and then changes. Governments can change a law that effects your code. Marketing might be a stakeholder. A specific target audience for the product might add extra salt.
By separating all those interests, preferable using interfaces, we can make sure that each chef only puts salt in their own pot of porridge.
ps. Developers sharing responsibility for code is a good thing. We are not stakeholders in this example, as long as we work as a team.
]]>It is very rare that a system has a complete documentation of its feature set. When doing a rewrite you still have to figure out what to implement. Often that is a big part of the job. That also makes it really hard to estimate the size of the rewrite.
Legacy code contains a lot of information. If you don’t know the code well, it is hard to know if it is domain complexity or accidental complexity. If it is domain complexity, the new system will be as hard to understand, but in a new, unfamiliar way.
New code has a tendency to be more flaky than old code. Not true everywhere. But those of you who hit this site, while I figured out this or that, knows how my 404-page looks. I have also not written any blogs in like forever, while working on the website. An old codebase can be terrible to work in, but it is often running in production and creating value.
When the code is something you own, its condition is in your hands. If hard to change code is always thrown out, we miss a chance to learn. And it is wasteful. Imagine moving house instead of spring cleaning. The skills we need for refactoring will make our software better in a way no rewrite ever will.
So learn how to take care of your code. Mend it and refactor it. Use patterns that will make it possible to replace parts when they get outdated, without tearing out all the domain code. The grass is not always greener in green field development.
]]>The same way, testing the untestable looks good on your resume. Used careless, it is also a way to allow sloppy software design. The goal is code that is easy to test. Because code that is easy to test is easier to work with, long term. A powerful tool for testing can become a liability. Awesome testing skills become a danger, if it leads to code that had no design pressure.
We need skills for the life we have, including its stress and hard to test code. But don’t confuse necessity with virtue. To build the world we want to have, we have to hone skills for such a world. It can be removing the cause of stress or getting better at software architecture. It will make our old skills a bit less valuable. Allow yourself to grieve that. it will also require us to do things we are not that good at yet. It is ok to find that scary. Just don’t let today’s skills dictate tomorrow’s reality.
]]>It is not always the case that we immediately spot the reason for an error in a codebase. Sometimes it is hard to find due to the design. In other cases the definition of correct behaviour is the problem. It might also be a lack in understanding when it comes to the technology used. This checklist is useful regardless of your knowledge of the language you are debugging. Depending on domain knowledge, technical knowledge and the state of the code base, how long the steps take and what information they give, will vary. This is, as most knowledge work, best done together with someone else, or with an entire team.
Write a test, of some kind, that captures the unintended behaviour. In worst case it is a description of steps to take written on a piece of paper. Best case is a unit test. This will define where we see the problem, with its setup and the state it leaves the program in.
Do we know for sure that this is a problem, not just a state where the behaviour is not clearly defined? Make sure that we know what the code is supposed to do in this particular case.
Are we sure that this is where the problem is caused? Check that the in-data is correct, and that the data out is not as expected. Try to narrow it down, define as little code as possible where the error might be.
Has it ever worked? If it has, what has changed since then? Version control is your friend here.
Is the IDE saying anything? A real development environment uses parts of the same algorithms as the compiler/transpiler/interpreter, to be able to give hints and syntax highlighting. There is also often static code analysis tools that can highlight practises that make the code fragile. Use tools.
Are there inputs, not stated as such, in the code we are looking at? Some code use state that is external in some way. One way to check this is by trying to write a unit test, instead of an integration test. What do we need in our setup to make it work? The state could be a global variable used by a collaborator, today’s date, or some settings in the system. Make sure that we know all the actual input data to the code we are investigating. Try to make the implicit input explicit when testing the code.
If there is comparing going on, is it done correctly (for that language)?
Do we know what could be null/nil/empty? Keeping null-checks at the boundaries of code makes this easier. Use the tools the language provide to deal with missing data.
Are data-structures used as intended? If iteration happens, are the boundaries the right one? Do the data-structures have any quirks in this framework?
Are there other language features that could be a problem? In Python, default arguments can turn into singletons. In ObjectiveC a method call on a deallocated object will return 0, or nil, but succeed. Try to rewrite the code, even if it turns it bulkier, just to see if misdirected “cleverness” might be the problem. Then read the documentation to understand what happens if the behaviour changes.
Is the flow of execution as we think it is? Use a debugger to step through the calls, following the control flow. Test cases can also be run in debug-mode. Make sure that there are no code skipped. One example is if code is executed as part of a condition, that is already evaluated as true, and therefore skipped.
Are we working with asynchronous code? If we are, then make sure that it is done correctly. Test ways to make sure that all of the suspect code is run synchronous, to eliminate logic errors that are not timing related , even if the code can never run like that in production.
Is everything what we think it is? Is the runtime scope clear? Do we have inheritance, this/self references, variables or functions that might shadow each other, or other things that might not be what we assume that they are? Do we reuse variable names or references? Might there be things where ownership is unclear and it is garbage collected? Use a debugger, or print statements, to check that things are what we expect. (Playing Destiny’s Child while doing this is optional, but it is a good reminder that scope in JavaScript is tricky.)
Take a break, if you have not already. At this point I might start searching the internet, or try writing a question at Stack Overflow. (Often the solution is in writing the post, not posting it.) I might also call a friend. My experience is that the harder the answer is to find, on the internet, the more likely it is that the mistake made is really basic.
Hope this list helps. I will use it the next time I get stuck on code not working as I intended.
How do you find your mistakes? Do you have anything to add? Have I missed anything language specific that is not included in the steps above?
]]>Split up the thing you are testing. Create a collaborator and test that separately or just split up the function. Splitting up view logic and rendering is nice and make testing easier.
Cheat codes: “separation of concerns”, “model view controller”, “view model - model view”
Sometimes the test depends on a system state or some other thing that is hard to control in the test. Inject the tricky thing as a dependency (fancy word for parameter) to the function/method. Today’s date should always be injected as a dependency if used.
Cheat codes: “dependency injection”
Wrap the framework in your own code and create a double for the wrapper. That will also isolate the framework, make it easier to adapt, replace and upgrade.
Cheat code: “ports and adapters”, “Hexagonal design”
Try to avoid side effects in your code as far as possible. Isolate necessary side effects (as sending/getting data) to specific areas of the code — the shell. A function or method that does not return anything, aka a void function, is a sign of a side effect in action. Make sure void functions do not contain any conditionals (if etc.). Write the rest of the code without side effects, levering data. If that is the only place containing logic, it is the part most important to test. And that can be done without tricky things as mocks.
Cheat code: “pure functions”, “io monads”, “functional core - imperative shell”
Sources:
]]>As a developer I spend my work days submerged in code. That is my work environment, together with all the tooling that come with it. For work to be pleasant it matters how the code is written. And just as software architecture, with its patterns and structure, come form the architecture of houses, there is now software interior design. I like to share some of my principles around it.
In the red-green-refactor cycle, when a test is red, that was expected to turn green, we need it to provide feedback. When the code is not doing what we think it should, one red test has a lot more information than ten. With only one red test at the time, we can be sure that it is the latest change we did that is not working. When writing trivial code this will never happen. But not all code is trivial, and some code get less trivial just before lunch or during a bad day.
Code that is designed to be tested is also designed to be reused. Tests are code using your units. When figuring out the interaction between code and test, the API of the unit will probably change. With great refactoring tools changing multiple tests are quickly done. But still, having to repair something, that has not brought value yet, is wasteful.
It can be hard to know how many tests that is enough, before you start implementing them. Tests are code that have to be maintained, and take time to run. So having just enough tests is really valuable. If the first step is to invent all tests that might be useful, our inventive power might make us a bit too productive. We might create tests that end up being waste. One effect of red-green-refactor is that no tests can be written for code that is already implementing the functionality tested, since you need to start with a test that is red. That prevents us from writing duplicate tests.
Just like a backlog contains stories to implement later, a test file can contain a list of test descriptions, names, or corner cases. That can be our outer loop. For the inner loop I want red-green-refactor, for one test at a time, one step at the time.
ps. If the code got too clever too early and you think that you might not have full test coverage — there is a solution. To make sure that everything the code does is covered with tests, mutation testing can be used. Mutation testing is when you change the code to test if it is covered by a test. A “mutant” is introduced by changing a constant, swapping a conditional or something else that should modify the functionality of the code. When a mutant is introduced and no tests go red, you can write a new one that does fail. That test is then red, and when the code is restored, it turns green. That way there will be only the tests needed, and hopefully all the tests needed.
]]>It is important to start with a failing test, also a simple one. Knowing that feedback is always available, and easy to reach for, will enable us to correct our work constantly. TDD could also have been named Feedback Driven Development. It is not the final test that is its strongest feature. If the function is simple enough to write a correct test for at once, then it is ok. But the ‘red-green-refactor’ cycle of TDD is also intended to modify the tests. A first failing test (‘red’) can be to assert that true is false, just to make sure the test can be run. A first passing test (‘green’) can be that the function under test exists at all. Then the tests will evolve together with the code, always ready to verify the next small step of implementation.
When the feedback is constant, supporting the iterations and not only there to show the end goal, we can truly be guided by our tests. They will be a railing to hold on to, also when we need to take steps that are smaller than one completed test.
So make sure to have the system for feedback in place first, and design it to fit only the next step you plan to take. That way you will not lose your footing.
ps. Do not forget to refactor your tests.
ps2. Sometimes we write tests as a part of finding an earlier mistake, aka bug. Then the step-by-step test writing can also be a way to figure out how the code is actually working. That way we can slowly figure out how to test it. Otherwise we might get put down by the expectancy to produce a perfect test to reproduce the bug from start. The code where bugs hide are often harder to test.
]]>This is Test Driven Development (TDD) explained with Theory of Constraints.
]]>TL;DR; Use a linter for your code! And fix all errors and warnings. Your brain will thank you.
In software, a linter is a static code checker. It looks at syntax, code format and white space, spelling, coding conventions, patterns that might cause bugs and other things that is not related to business logic. A lot of them have configurable rules, ways to make exceptions (that can be used for gradual introduction in legacy projects) and ways to auto-correct your code.
I see a linter as a cognitive tool, something we use to relieve our brains so that there is more energy left for things like problem solving. Here are three ways linting does that:
Social negotiation takes energy. When a team has decided on the linting rules the discussion is done, or at least not constantly debatable. And it is enforced without any specific person having to take the fight. Have a pipeline for the code where linting is checked before code ends up in a flow shared by other developers.
Code that is regular is easier to read. Having a common standard is much more important than what standard you use. But the removing of noise only works fully if you do not let the linter add noise. Therefore it is important not to let any errors, or warnings stay. If you have something in your code that you want to keep, though the linter is protesting, make an explicit exception to silence the error or warning. As an extra, some linters can also recommend a simpler syntax for achieving the same behaviour. That can make your code less verbose without obfuscating it and then also remove noise.
A lot of what the linter does is things you would like to do, but now you do not have to. As with spell checking, you can find and fix all the deviations from how you want your code to look, while reading it and having it reviewed. But as with spell checking, that is neither the fun part of writing nor the most energising thing to give and get feedback about. Let the computer do the boring stuff.
Linting might find bugs. Especially in languages without a compile step, the checking for risky syntax is very valuable.
So, go and lint your code! And add the linting as an automatic step when writing code. That way you let the machine do a little more of the boring job, and leave more energy to do fun things, like problem solving.
]]>They go to the quality assurance team that tests finished products. There they find a lot of things that passed through a bottleneck, but got discarded. since they had shortages in quality. By moving parts of the QA before the bottleneck, they save the limiting station from working on things that are already broken.
What is the equivalent to this in software?
I do TDD and BDD! you might say. If we assume that the developers are the bottleneck I would say that it is rather like making sure that the products are not broken during or after they are at the bottleneck.
My suggestion is that we see user research and design sprints as our way to make sure that we do not have products that are already broken taking up valuable time at the bottlenecks. Every feature, that is not tested against a real user, risk being waste in process instead of work in progress already when it reaches the development team.
The best way to increase the capacity of a bottleneck is to find what it should not do. By doing design sprints and user research you can try a lot of ideas that do not have to go though the full development cycle. (It has other advantages too.) By investing in usability and design a lot of redo and undo can be saved.
Make sure that all tasks that get turned into code has first been checked that they actually should be implemented. That is how user research limits waste in process.
]]>