Lots of programmers. At least one person doing systems architecture and one researching user behavior.
Trouble getting started, trouble making decisions, trouble making decisions quickly, no clear leadership since it was based on consensus, no deadlines and perhaps a lack of motivation.
Chapter 0
Donald Knuth. He apparently wrote one of the most respected texts in software devlopment
Programmers start counting at zero
A tinkerer, who was obsessed with modifying programs.
Two-thirds.
Frederick P. Brooks, Jr.
Chapter 1
Programmers
A program that keeps track of tasks needed to be done for a programming project
Open source application foundation
Chandler
Organize and share calendars, email, to-do lists, and other management stuff.
Scary.
Kept leading him on a “treasure hunt” and was impossible to estimate how much time it would take to fix.
An important problem that they did not have a consensus on how to attack.
Lateness
Operating system for the IBM System/360
Adding manpower to a late software project makes it later.
One-sixth
Half
When a task can be split among many workers with no communication among them.
Source code is the human written code used to design the program, with it you can tinker and change things. The .exe on your computer is simply a binary file full of machine code that would be near-impossible for a human to understand.
a “publish and share” mindset
A great programmer is able to produce ten times as much work in a given amount of time vs a mediocre one, and typically five times as good
One idea is to build software as you would a cathedral, a small group working carefully and perhaps in isolation. The other style was to release early and often while being totally open.
Kind of, it introduced “linus’s law” which says “given enough eyeballs, all bugs are shallow” and the counter point “Provided the development coordinatior has a communications medium at least as good as the internet, and knows how to lead without coercion, many heads are inevitably better than one.”
“The key is getting exciting work going; the rest of it will take care of itself”
Chapter 2
Until about the 1990s. He left after protests started happening about Lotus’s business and copyright practices. He walked away because he sympathized with open-source ideals.
When there is a disagreement development can split into rival camps
Science means building upon the work of others (open source), witchcraft means guarding a small secret without sharing it (traditional software)
“oNLine System” (NLS) – created by Engelbart and demonstrated in 1968 at the San Francisco Convention Center.
The phrase “pulling oneself up by the bootstraps”
Xerox’s Palo Alto Research center
“Trilogy” by the FBI, The Federal Aviation Administration’s Advanced Automation System, and the Pentagon’s “Future Combat System”
Widely cited past reports about the failures of software ventures is greatly exaggerated and not as bleak as reported.
It may be very difficult to provide an exact objective prediction of the time required to develop a piece of software, but estimation is possible. However, we need to realize our shortcomings and acknowledge that we cannot say for certain and may be way off.
Chapter 3
Hertzfeld had left apple, Kapor had done time as a DJ, Sagen and Cho did some research on data structures.
Because you’re unlikely to get it right the first time.
Researched user behavior patterns.
He oversaw the tools the programmers would use.
A computer stopping everything its doing and outputting a file of its memory. Because some of the earliest computers were built out of wire coils aka ferrite cores.
He described programmers work as building piles of abstractions, designing our own abstractions and then pile them on top of layers we got from somebody else.
Assembly language
A compiler.
The programmer’s time becomes more and more valuable compared to the computer’s processing power. It may not always be worthwhile to be as efficient as possible managing small bits of computational power.
When the program is run the source code is translated line by line.
October 2002
Chapter 4
1. What do “front ends” and “back ends” mean to software developers?
Front end refers to what a user sees, where they interact with the program. Back end refers to the processing and logic of the program.
2. What did the Lego Hypothesis refer to?
The idea that programs of the future will be built by already created parts and pieces put together like legos.
3. Give one reason why the Lego Hypothesis seems to not work so well.
Inconsistency with the “building blocks” inside programs makes it difficult to integrate a standard set of blocks.
Chapter 5
1. What is the three-way trade-off that many software projects struggle to overcome.
Fast, cheap, or good
2. What is the more recent definition of “geek?”
Someone who has an easier time interacting with computers than other humans.
3. What does “refactoring” mean to programmers?
Rewriting code to make it easier to read, shorter, or more clear.
4. What is “yak-shaving?”
A seemingly pointless activity which is actually necessary to solve a problem which solves a problem and so on until you solve the real problem you’re working on.
Chapter 6
1. What is term “edge cases” referring to in software development?
An unlikely scenario or extreme possibility that you may need to account for.
2. Summarize briefly Linus Torvalds advice about “large projects” give in 2004
Start small, grow your projects only as needed.
Chapter 7
1. Briefly describe Hungarian notation
When naming a variable, an identifying prefix is added.
2. What does the author state is the “...single most challenging demand of software development.”
Communication between programmers, programmers to machines, and machines to users.
Chapter 8
1. What does “eat your own dogfood” mean?
Actually using the programs you’re developing.
2. Quote: “When people ask for numbers that far out, the traditional thing that engineers do ....” When discussing the timeline for Chandler, how was the quote above completed?
“…is make them up.”
Chapter 9
Making a mess of your code using goto statements.
Not exactly, but it helped lay the foundation for good practices and did help.
It seems to be highly debated (for instance whether you should plan a lot vs plan less) so there doesn’t seem to be a definite answer thus far.
Programmers would not be able to work until certain stages were complete, start working before they got the requirements, difficulties meshing huge chunks of code together at the end of the project, delays, confusion, general mayhem and bedlam.
Promoting individuals and interactions over tools and processes, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change vs following a plan.
The majority practiced no particular practice at all and simply winged it. This represented about 30% of the answers.
The ‘Joel Test’ is a set of principles to figure out whether or not a particular organization has their act together. The questions are as follows:“Do you use source control? Can you make a build in one step? Do you make daily builds? Do you have a bug database? Do you fix bugs before writing new code? DO you have an up-to-date schedule? Do you have a spec? Do programmers have quiet working conditions? Do you use the best tools money can buy? Do you have testers? Do new candidates write code during their interview? Do you do hallway usability testing?
According to Spolsky, Microsoft has a perfect score of 12/12 full-time. However, they’ve gotten fatigued and it takes them an enormous time to put out products.
The author’s personal law, which states; “Software is easy to make, except when you want it to do something new.” But.. “The only software that’s worth making is software that does something new.”
Chapter 10
In the story, the King of the Turtles (and really all of turtlekind) are brought down because of a single failure point. They stacked themselves so high that they became extremely susceptible to failure. For software designers, stacking abstractions can lead to a similar catastrophe.
(Circuits built can be found on the CS160 Assignments page)
Chapter 11
1. Briefly describe the four gates explained in Chapter 11. Describe the behavior of each gate based on the input values to the gate.
The first gate is an “and” gate, and will output a voltage only if all inputs have a voltage. The second is an “or” gate which will output a voltage if any of its inputs carry a voltage. The third is a “nand” gate, which will output a voltage unless all inputs carry a voltage. Finally we have a “nor” gate, which will output a voltage only if all inputs carry no voltage.
Chapter 12
1. A half adder is built from how many "sub components" and has how many inputs and outputs?
A half adder is built from 2 sub-components, a XOR gate and an AND gate. It has two inputs and two outputs (sum out + carry out).
2. A full adder is built from how many "sub components" and has how many inputs and outputs?
A full adder consists of 5 sub components, 2 XOR gates, 2 AND gates, plus an OR gate. It is made of two half-adders plus an OR gate.
3. How many total inputs and outputs are there for an 8-bit adding circuit?
There are 16 total inputs and the book has 9 total outputs (one is an overflow bulb).
4. How many total transistors are needed for the ripple version of the 8-bit adder?
144 transistors/relays are required. Although in real life they’re exceptionally tiny.
Chapter 15
A byte is a sequence of 8 bits.
Unsigned byte: [0,255], Signed byte: [-128,127]
The 32s column
Hexadecimal
Each digit of a base 16 number represents half a byte, hexadecimal numbers can represent a lot of information in a short sequence, and converting from binary to hexadecimal is straightforward.
using a calculator?
Split it up into nibbles: 1010, 1100, 0011, then convert these values to hex; A, C, 3. The number in hexadecimal = AC3
The 256ths column
Take the number divided by the base you want to convert to raised to the power of the largest colum that divides into the number (for example, to convert 300 to binary you would start with the 2^8 column, since 256 is the largest power of 2 that goes into 300). Then, take the remainder of your division and divide that by the base you are converting to raised to the next largest column (to get to the next column we subtract one from the power each time, eg. We would do 2^7, then 2^6…in this example), and so forth until you get to the column base^0. As we get past base 10 we use the appropriate letter to represent our missing digits. (eg. 10 becomes A, 11 becomes B…).
Chapter 16
1 Kilobyte = 1024 bytes, 1 megabyte = 2^20 bytes, 1 gigabyte = 2^30 bytes, 1 terrabyte = 2^40 bytes, and 1 petabyte = 2^50 bytes
Kilo comes from the Greek “Khilioi” and means a thousand, mega comes from “Megas” which means great, giga is from “Gigas” which means giant, tera originates from “Teras” which means monster, as far as I can tell peta does not come from a Greek word – but is instead from the International System of Units and means the fifth power of 1000.
Ram is reset when it loses power, and any data stored will be lost as everything switches off.
Link: Big Ball of Mud
There are at least two methods of writing code, both according to this article and my own personal experience. One method of course being the quick and dirty “get it out the door” technique, with the other being a slower yet more robust strategy. I do believe that there is a time and place for each, and which one you should choose depends entirely on the circumstances of your work.
Let’s consider a few different scenarios where we can pick and choose our plan of attack to maximize the strengths of each technique when appropriate. Imagine you’re writing a piece of software for your own personal use. Perhaps it’s something that will automate your work to some extent or just a nifty tool. What should we use and why? To determine that we can look at a number of factors:
The program is purely for our benefit, so we can presume we’re going to be the only ones using it. This means we don’t need to sanitize our inputs, add features we wouldn’t personally use, and it doesn’t have to be pretty. For similar reasons, it’s unlikely that the program or user base would grow, and there seems no need to ever update the code past whatever corrections we may need to make. Finally, assuming we did put out a program as fast as possible, what could go wrong? Depending on what exactly you’re automating, probably not much. Assuming mistakes are limited it’s unlikely anything catastrophic will go wrong.
Now, let’s look at those same factors from the perspective of a software engineer writing a program for a large financial institution. Who is going to be using the program? In our scenario we can assume a sizeable user base with limited tech experience. This means we will need to at the very least sanitize their inputs to make sure they don’t set themselves or something else on fire, add some rigidity so they can’t accidentally take down the building, and whatever other measures we deem appropriate. The program could presumably grow to be pretty large, this piece of software is going to be a staple for our company and will most likely be pushed onto another generation of developers once we’ve run our course and had our souls crushed. They will need to be able to understand at the very minimum what the program does, so it can’t be a massive ball of spiders. Assuming we did go the quick and easy route and pushed it out as soon as humanly possible without regard for human life? Well, we could be fired or potentially sued when a clerk somehow loses all of the transactions for the day by entering something we shouldn’t have let them – we could cost a company millions of rubles in some obscure scenario we failed to account for.
In the real world, things might not be so clear cut – and it’s not strictly one or the other. Sometimes the best option might be a half-measure between the two. In fact, I would recommend you do your own analysis at every level appropriate, there may be parts of a program that can skirt by with a bare minimum while others may require intense testing and safety measures as well as a high degree of organization and factoring.
Link: DevOps for hybrid cloud: an IBM point of view
While DevOps seems to be a newer movement in software development, it looks to me that a lot of the core principals have been around for some time. Many of what is described here shares quite a bit in common with excerpts from The Mythical Man-Month. “Lean startup” for example was already established pretty well by Frederick P. Brooks Jr. advice to make a project only as large as it needs to be. I would actually be surprised if many (or at least some) of these practices were not already the standard considering many of them were touched on by Brooks Jr. in 1975.
What is surprising to me is the emphasis on the “cloud” which I’ve always figured to be just a silly buzzword for a server, but I suppose it’s starting to stick. I imagine in this case it mostly refers to using products similar to what we’ve been using in class to manage our source code and I can see how something like that would become invaluable for a large team to collaborate and join code plus manage updates and merge. In fact doing it any other way sounds truly awful.
Something that really jumped out at me was the “fail fast” strategy, encouraging people to try different approaches and be a little creative without fear of being penalized. I think that’s really where creativity flourishes. If you are reprimanded for stepping out of line and deviating from the norm you’re never going to try anything new – and if you don’t try anything new then innovation goes out the window.
Time and time again it seems to be that the largest issue facing programmers is one of planning, scheduling, and communication. As pointed out in the article, there does not seem to be anyone one good solution. While there are some good key practices (such as pointed out in the DevOps article) none of them will prevent every disaster, and I think the best we could hope to aim for is just minimizing the amount of disasters and the damage when they do inevitably occur.