Abstract
We’re going to change gears. Having spent a couple of chapters looking at the management of software development, we’re now going to take a closer look at software development itself, and the processes that involves.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
The ability to translate from technical-speak to business-speak is a rare and precious attribute in a developer. Because they spend all their time mired in technical details it can be difficult to remember what a non-technical audience can be expected to understand, and even harder to find ways of isolating the non-technical aspects and ramifications of a technical issue and talking only about those. The developers who do it the best often speak almost entirely in metaphors and analogies—often spectacularly creative ones—when talking to their non-technical colleagues. However many developers just trot out the raw technical stuff, and expect their audience—you—to do their own translating into non-tech-speak.
- 2.
We are assuming here that the coder is tasked with building a new feature. If they are doing support work rather than active development, this might not be the case—more on this in the next chapter.
- 3.
Unless your calculator is accidentally set to work in radians, in which case your homework isn’t going to go well tonight.
- 4.
Okay, not interestingly for most people, but interestingly for me, so I’m going to tell you anyway.
- 5.
Philosophers are much better at asking new questions than providing answers.
- 6.
For example, there’s a long-standing convention in some circles to use “shall” and “should” quite a lot, to delineate requirements and recommendations respectively. Such as: “When the user clicks the big red button the system shall launch the missiles, and the system should notify the user that it has done so.”
- 7.
This is very similar to what happens to software developers who focus on neat code rather than a great user experience, as I described above. (See, coders aren’t so very different from other people.)
- 8.
I’ll keep capitalizing it, to make clear that I’m using “story” as a technical term, rather than using it to mean an actual story.
- 9.
Who am I kidding? There is always time pressure.
- 10.
This is what Ada Lovelace had to put up with. When Charles Babbage designed his mechanical Analytical Engine over 150 years ago, she wrote software for it to enable it to do some mathematical calculations, but was never able to try it out because the Analytical Engine was never built.
- 11.
If any of this is coming as a surprise to you then feel free to ask your parent or teacher for help.
- 12.
If you want a really clear explanation of how electrical circuits can be used to do math, try Code: The Hidden Language of Computer Hardware and Software by Charles Petzold. It walks you through how computers work, starting with the idea of two wires connecting a battery to a light-bulb and working its way up from there.
- 13.
One thing I’m glossing over in my simplification is all the intermediary step. If you write software in one programming language it might first get translated to another programming language that a human could theoretically read, then translated into some intermediary language that still isn’t quite raw binary but is pretty unintelligible to humans, and only then be turned into binary. If you’re interested, google “assembly code,” “machine code,” or “bytecode” and see where it takes you.
- 14.
Or so I’m told—my embarrassing confession is that I don’t hold a driver’s license.
- 15.
I know, I know, that sounds pointless and contrived, but remember that in 2014 the “Yo” app was valued at over $5m and had 3m downloads and literally all it did was let you send the word “Yo” to other people. Even pointless and contrived software ideas can also be viable businesses.
- 16.
The below code isn’t written in any particular programming language—it’s written in a mishmash of different languages to make it easy to read if you don’t know any particular languages.
- 17.
This, by the way, is why “code” is a terrible name for the stuff software developers write. When we think of codes we think of things that are deliberately obscure, like the codes spies use to prevent eavesdroppers from understanding them, or discount codes that are designed to be unguessable so that only people who know them can get the discounts. When writing computer code, conversely, developers are desperately trying to be as explicit and clear as possible.
- 18.
In most programming language everything (properties, class names, functions) has to be defined in a single “word” to make it easier for computers to read; the way around this is normally either to_add_underscores or to jamTheWordsUpTogether depending on the language.
- 19.
Caveat: OOP has several problems and limitations, and in the last few years a new movement called “Functional Programming” has been gaining in popularity. However, an exploration of FP is beyond the scope of this book.
- 20.
Not the group of disgraced leaders of the Chinese Cultural Revolution with the same name.
- 21.
But be wary of trusting them when they tell you how the code should be changed—all will be revealed next chapter.
- 22.
For various reasons, when a software program is large enough to comprise more than about 100 lines of code, it is normally broken up into several files rather than one big one. One main reason is ease of navigation. Coders spend a lot of time needing to hop back and forth between parts of their code, because different chunks are interrelated, and it’s easier to alternate between two different documents than to continually scroll up and down in one long one.
- 23.
Bonus points if, when you identify the breaking change, you can see at a glance who made that change, and therefore who will be buying apologetic cupcakes for the team the next day.
- 24.
In Chapter 6 we’ll be looking at lots of the terminology that software developers use, and you’ll learn, if you hadn’t already noticed, just how much software developers love silly names.
- 25.
A particular problem is getting programmers of different skill and experience levels to work together—a junior coder may well be too intimidated by a senior partner to make suggestions, or they may be slightly too keen to offer up suggestions whose disadvantages take a while for the senior coder to explain each time, and so on.
- 26.
The Effectiveness of Pair Programming: A Meta-Analysis, Jo E. Hannay, Tore Dybå, Erik Arisholm, Dag I.K. Sjøberg, 2009.
- 27.
As discussed in previous chapters, in an ideal world one builds software in incremental small chunks, each of which can be released as soon as it’s built. When things are less elegantly managed, it’s often the case that the software gets into a state where it’s not ready for release because something major had to be broken to enable something new to be built, and that major thing stays broken for months on end.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2017 Patrick Gleeson
About this chapter
Cite this chapter
Gleeson, P. (2017). What Do They Do All Day?. In: Working with Coders. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-2701-5_4
Download citation
DOI: https://doi.org/10.1007/978-1-4842-2701-5_4
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-2700-8
Online ISBN: 978-1-4842-2701-5
eBook Packages: Business and ManagementApress Access BooksBusiness and Management (R0)