34

In my experience as software developer, I found work situations where you have to deliver a project in a very short time and with a very small number of resources (included team members).

Your boss doesn't really care about nor understand the importance of testing (especially automated) and other quality aspects (or he may understand the importance of those, but maybe he is being pushed by his manager to ignore it).

Apart from "quitting the job", which actions would you take? Would you take shortcuts and if yes which ones? Something else?

Improve this question
5
  • 2
    The boss may understand the importance of testing, but may be he is being pushed by his manager to ignore it... – Solar Mike Sep 8 '19 at 9:01
  • true, that is a possible situation. Let me edit the question. – Randomize Sep 8 '19 at 9:03
  • 8
    While I really understand the sentiment of your question, it is not really clear what you are trying to get answered. Is it about whether taking short-cuts is unavoidable? Are you asking for what to do in your situation or do you want to know how to deliver in a short time?. – Helena Sep 8 '19 at 19:31
  • 90% of my job today involves figuring out which corners you can cut and which will cause it all to come crashing down. Management rarely cares about the right way and sees it as an impediment to progress. – prieber Sep 10 '19 at 23:15
  • I don’t think that this question is opinion based. There are a number of software development methodologies that offer objective answers to this question. It would, however, perhaps be better suited for the Project Management SE site. – nick012000 Jan 24 '20 at 22:46
107

Yes, the real world is a lot different to what you are taught at university.

When you work for a business, the job is to make a profit, not deliver software according to an idealised software development process. A lot of the time these things overlap, but not always.

It is perfectly legitimate to "cut corners" from time to time.

While you may lament that your boss doesn't understand the importance of software testing, they may lament that you are unaware of the business pressures that impact the business. That means that things may need to be shipped without automated testing. I don't think it's fair to categorize your boss as ignoring the importance of testing. They obviously just assign it a different degree of importance than you do, or aware of different factors to what you are.

Your role in this situation is to highlight the risks associated with not having automated testing to your manager, and allow them to make a judgement call with all the information at hand.

Improve this answer
1
  • Comments are not for extended discussion; this conversation has been moved to chat. – Neo Sep 9 '19 at 13:22
22

Software development is about managing risk in unknown or uncertain environments while frequently doing novel work. Making tradeoffs about time, scope, and quality happen all the time. The important thing to do is to help stakeholders understand the impact of their decisions on the project. To me, responses of "quit the job" or "blow the whistle" would be reserved for cases where the decisions made for the project would have severe consequences for life and safety, privacy or confidentiality, security, or some other 'critical factor' (which would vary depending on what you are building).

Unfortunately, there are no best practices or algorithms for making these decisions. Learning comes with time and experience. You can study the experiences of others, but the best experiences are yours and working through these trade-offs with your colleagues to understand the rationale for the decision making process. Decisions like this are highly context-sensitive.

Improve this answer
20

Yes, technical debt is a perfectly valid decision in many cases; just like taking out real debt is a valid business decision in many cases to advance the business goals. (We'll make $$$ if we had $ capital to invest in the business, so getting a loan for $ and paying $$ back still puts us ahead in the long run.)

But in my opinion skipping automated tests is never a good loan to take. The time saved is often used up, not in years or months, but weeks. (And it gets exponentially harder to pay down.) Unless the due date is today, don't skip tests; it won't be worth it.

This is one reason to follow TDD IMHO. Because we are then never in a situation where we can say a feature is "done", but "still needs to be tested". It's just too tempting for a non-technical manager to lop off the tests and call it done. They now only have the much better options of cutting scope, rescheduling delivery, or when really necessary using other types of technical debt (abusing state management, skipping robust architectures, etc.).

Improve this answer
16
  • 4
    It doesn't matter very much that the product which missed deadline and hence got canceled had no technical debt, does it? – Tero Lahtinen Sep 9 '19 at 6:59
  • 4
    @jww I don't see any evidence that supports what you are saying. The Anthem breach would appear to have been caused by a successful phishing attack, and Equifax breach appears to have been caused by not staying current with security patches. I also don't see any evidence that tax payers are footing the bill over the fines. There are many good examples where in some particular circumstance, not going into technical debt would have resulted in a better outcome, but these two are examples of such. – Gregory Currie Sep 9 '19 at 7:10
  • 2
    @JörgWMittag that's your very narrow personal definition that's not the commonly accepted one. From wikipedia: Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. – Frank Hopkins Sep 9 '19 at 13:00
  • 1
    @JörgWMittag and yet from your link the definition is exactly that of going for speed now and repay that debt later by taking the time to do it right (including the lessons you've learned with the fast and dirty approach). So I see no contradiction in technical debt including corner cutting. The difference he seems to make is that the code you write with limited algorithmic functionality should still be good code from a style perspective, i.e. be able to refactor. Obviously that initial application of the term was also specific to his project and with common acceptance it got broadened. – Frank Hopkins Sep 9 '19 at 14:54
  • 1
    @JörgWMittag And the clean code isn't a requirement for something to be technical debt or not, it just means that without it, paying it back is much harder. Btw, same blog/wiki that hosts that video has a definition of technical debt that nicely fits with the general definition that is far broader than your catch-22 description: wiki.c2.com/?TechnicalDebt – Frank Hopkins Sep 9 '19 at 14:57
8

What you call "shortcuts" are really trade-offs, and they are inherent in any project, in any discipline, you will undertake. It is inescapable. There is an idiom in the engineering world (yes, I put this in a comment above): You can do it well, you can do it fast, or you can do cheap. In the best case, you get to pick 2, so the decision needs to be made on which 2 are most important for the given circumstance.

To use your situation as an example, you have a small team (cheap) and a tight deadline (fast), so it follows that what you build will probably have a lot of bugs and you may not get to do the testing you want to do. This is the decision your manager has made, and he will have to deal with the consequences. You want to do more testing to build a better product? He will either have to give you more time (lose out on 'fast'), or add more people to do the testing (lose out on 'cheap'). Those just may not be options for the project. This is inescapable.

So quitting your job won't solve anything, because this principle will be there wherever you go. The most you could do is find another employer who maybe puts an emphasis on a different part of the triad, but even that will vary from project to project. They are making decisions just like your current manager.

Any decision made against this triad will have consequences and someone will need to figure out if they are acceptable. Slowing down to build a better product means you might miss a deadline. Adding more people means they won't be working on something else. Building it fast and cheap means spending more time on supporting it later (or living with a shoddy product). Depending on the requirements, any of these decisions might be valid. The key is understanding the trade-offs, what they mean for the business, and making sure the decision-makers understand them. That's one of the most important skills you can have.

Improve this answer
1
  • 1
    It should also be noted that we don't really even know how to build a project that's extremely high quality. Most programmers have most of their experience on the cheap and fast side; projects that need extreme reliability (the Shuttle software comes to mind) are developed completely differently from both common practice and academic ideals. We may have some ideas how to do things "right", but they seem to be tenuous at best, and outright counter-productive in other cases, and usually haven't really been tested in practice all that much, for whatever reason. – Luaan Sep 9 '19 at 11:25
6

“Trade-offs” are almost always required, but delivering crap is not. If you find yourself being asked to deliver garbage, consider walking away. Or, if the software concerns finance, information security, or health, make that run away. (Because when it fails, management will be looking for scapegoats.)

Improve this answer
1
  • The OP has explicitly asked for solutions that don't involve quitting the job. – Gregory Currie Sep 8 '19 at 22:42
4

What actions to take: The first is to explain to your manager what cost the shortcut is likely to make to the company. Worst case the shortcut means endangering and possibly killing people. Most harmless case is that you fix the problem next week and no harm is done. Your manager needs to know what it is to make an educated decision.

The next action is to take steps that "fix" the shortcut if needed. Sometimes it's not needed. Sometimes you write software for a single use, and it either works or it doesn't, and you can see whether it worked. In that case, if the software worked, then it doesn't matter what shortcuts you took.

Sometimes shortcuts are justified. Say you are the only developer, and software must be ready at date X. If you are ready at date X, the company makes a lot of money, enough to hire two more developers. If you are not ready at date X, the company makes no money and you lose your job. Clearly you take the shortcut. If everything works fine, the two extra developers can more than clean up all the mess that was created to be fast.

What is good is if you can educate your manager that if your software is in a good state, then you can take shortcuts sometimes. You may be able to do a job that should take four weeks in one week (but now the software is all messed up). But you can do that only once, then you need to spend three weeks to clean up. If you don't clean up, then the next four weeks worth of work either takes seven weeks including cleanup, or four weeks leaving even more mess, and after that you are in trouble.

Improve this answer
3

I'd like to challenge the premise of your question.

Who is the expert on developing software? You or your boss? Your boss hired you because you are an expert, a professional. Automatic testing is part of your work. So act like a professional and implement automatic testing if you deem it necessary. Does your boss also decide on whether you click to move to the next line or use your keyboard? Does your boss decide whether you use tabs or spaces? Your boss has no say in that, unless they're a programmer too. Same for automatic testing. They're part of your work and your boss has no say in that either.

Sure, sometimes you want to make trade-offs, but bosses can only make trade-offs on features. They can also request you to try and program faster. But only you, the professional they hired to develop, get to decide on the code quality trade-offs. It's your job to know what makes you code faster, not theirs.

Improve this answer
5
  • 1
    Great to see an answer like this. It's such an abdication of responsibility to push decisions on refactoring and testing on your boss. – monocell Sep 9 '19 at 8:25
  • 1
    You're getting down-votes from the same people that would tell a crane operator where to put his stamps (whatever those square plateaus are called), a pilot to ignore the safety-checklist, gun-users without trigger discipline. Shame really, why would we developers even learn our trade when there's so many that know how to do what we're supposed to do? ... but still cannot change a cartridge in a printer – rkeet Sep 9 '19 at 9:24
  • 1
    Your experience with "bosses" seems limited to unqualified morons. Lead engineers are also experts and professionals; the difference is, they're the kind of professional who didn't just graduate school last week, and may have even accrued some experience along the way. – hobbs Sep 9 '19 at 9:38
  • @hobbs It's in their name, lead engineer. Of course other developers on your team get to say a thing or two about developing. Especially if they're more experienced than you. They are professional developers too. Bosses who do not know our trade shouldn't. They should stick to their trade, being boss. – Belle Sep 9 '19 at 9:44
  • 2
    @Cyonis and being boss contains deciding how to spend money and how to deal with risk, i.e. whether to use a crane or just a bunch of ladders. Sure, there are tipping points where just using ladders is getting insane(ly dangerous), but in general it's his prerogative to have his say in such matters. – Frank Hopkins Sep 9 '19 at 13:04

Not the answer you're looking for? Browse other questions tagged .