[onion2k]

For example, I don't want to spend my time testing, but I have to do it if I want to write high quality software.

Why?

Someone has to do the testing, obviously, but why does it have to be you just because you want to write good quality software? Why can't you work with a brilliant QA[1] team who can generate an awesome set of processes and tests based on your specifications? You don't have to do the bit you find boring if there's someone else around who loves doing it and will do a better job of it because they don't find it boring.

Giving up parts of the development process is part of being in a team. A very important part.

Using the idea in the article along with good knowledge of what's needed in the particular problem domain, it should be possible to use 'workshapes' to put together a very suitable team of people for a project.

[1] Important note for the unfamiliar: Most QA teams are actually QC teams. QA (quality assurance) has to happen from the very first stages of a project, putting in processes that assure the right level of quality will be met. QC (quality checking) happens at the end where someone goes through a project and makes sure it's been done well. If your "QA" only happens at the end then it's QC, and it's probably not helping you build the best product you're capable of building.

[lmm]

When you start dividing responsibilities horizontally like this, IME you end up producing worse software. Being responsible for testing drives you to good design. Being responsible for deployment raises considerations you might otherwise miss. When development and QA are separate it's all too common for only one to have an understanding of the actual customer requirements.

Better to slice vertically. Everyone takes responsibility for a small piece of functionality, end-to-end.

[logfromblammo]

If you have ever read about Carrot in Pratchett's Discworld series, you may have a new understanding of laziness.

Carrot, you see, is so lazy that he exercises every day, because it is easier to accomplish things in a fit body than in one that is fat and weak.

Testing your own code is that sort of laziness. You write automated unit tests so that you will never have to look at or touch that particular bit of code ever again.

Having that sort of laziness will also make you an expert in design, because good design allows you to write concise, maintainable code, which makes your job easier.

[aaronem]

That's not Carrot, that's Victor whatsisname from Moving Pictures.

[logfromblammo]

So it was. Victor Tugelbend. My memory is not what it once was. Or I assume it isn't.

[Udik]

Except that you'll pollute your code with all sorts of design decision and syntactic clutter that make sense only in the light of testing. Except that it will take you so much time to test trivial functionalities, you won't have time to write or just think about them better. Except that your tests won't actually capture all failure cases, but only those you could think of at the moment of writing them. Except that you'll spend a good percentage of your time maintaining tests that break for the wrong reasons - that is, perfectly working changes to your code.

Sure, testing can be extremely useful and important in some cases. I'm thinking of complex engines that power business flows and applications. Testing user interfaces and MVC controllers is hypercorrection and usually a waste of time.

[logfromblammo]

A quote from a Presbyterian sermon published in 1856 eventually evolved into a quote fraudulently attributed to Abraham Lincoln in a 1960 advertisement.

If you have 5 minutes to cut down a tree, spend 3 minutes sharpening your axe.

If you are cluttering your code to make your testing easier, you are attempting to sharpen your axe by repeatedly striking it with the trunk of a tree.

If your tests fail when refactoring working code to working code, your problem is the manner in which you write your tests. I have seen testing done well, and testing done poorly. And in light of the latter, I can see why someone might dismiss developer testing. Having both as a basis of comparison, the shop that used TDD accomplished a task in two months with 3 people that the other shop could never have accomplished in 2 whole years with 15 people.

The bad shop mandated testing, of course, as a cargo cult ritual, but metaphorically, in order to test the shear strength of a single bolt, you had to launch the whole Space Shuttle. I often saw methods written with a boolean parameter called IsUnitTest. I am not making this up.

That was a clear difference between smart-lazy and stupid-lazy. One shop sharpened the axe before cutting, and it was felled on time. The other held several hour-long meetings, decided to cut down the tree with a rubber mallet, declared that it would take about 20 minutes, and assigned the task to me entirely without my input. When I suggested an axe would work better, I was told that the mallet was already decided, and if I used an axe instead, I would be fired. When it was later discovered that I used the mallet to strike a splitting wedge, I was deemed to be undermining the axeless mandate, and was fired.

This is metaphor, but there is no hyperbole. This was the shop that banned me from using lambda expressions in C#, because other developers on the team could not understand them. In 2014.

Be smart-lazy. Do the simplest thing that will get the job done. If automated tests do not make your job easier in the long run, don't do them. If some design pattern would needlessly clutter your code for no benefit, don't use it. These decisions are easy to make when they are not being made for you.

[JustSomeNobody]

Before the code even gets to QA it needs to be functional and as bug free as possible. As a developer, I _hate_ it when my fellow developers send crap to QA because they could not be bothered to make it not crap. It is unprofessional.

The goal should be to produce SW that does not get rejected at QA.

[gambiting]

Yeah, I agree on principle. But sometimes you look bad in front of QA because you ask them to do their job. To give you an example - I was implementing an achievement for a console game. The achievement took roughly 3-4 hours to test fully. I was specifically told by my manager to do my best to make sure that it works,but not to spend time testing it myself,because it would be a waste of my time - it's QAs job to test things like this. So obviously, when the achievement didn't trigger after 4 hours of testing, I looked like a dick to QA,who just spent 4 hours testing this thing.

Unfortunately some people take this approach for everything and never test their code - that's bad.

[jdmichal]

Seems like you should have been able to give QA a game state that was close to the achievement. Even having QA burn 4 hours of time is wasteful when a game is nothing other than state that can be loaded to any arbitrary point.

[gambiting]

Yeah,but the achievement consisted of 44 individual triggers, and for the test they had to trigger all 44. You couldn't give them a state with 43 already triggered. Not to mention that if you change the achievement triggers you have to wipe the save data in make the new triggers work, so they had to start from scratch every time. But fortunately it only had to be done twice in the entire project.

[GordyMD]

Like that you have picked on the team aspect. We have a very exciting new feature in the works which focuses on presenting the team that you would be joining and how you will compliment each other in terms of how you collectively want to spend time.