Beginner's Mind @alexandreaquiles - Tumblr Blog

Posts

The first attack on the checkout problem may be made before coding is begun. In order **to fully ascertain the accuracy of the answers, it is necessary to have a hand-calculated check case with which to compare the answers which will later be calculated by the machine**. This means that stored program machines are never used for a true one-shot problem. There must always be an element of iteration to make it pay. The hand calculations can be done at any point during programming. Frequently, however, computers are operated by computing experts to prepare the problems as a service for engineers or scientists. In these cases **it is highly desirable that the "customer" prepare the check case, largely because logical errors and misunderstandings between the programmer and customer may be pointed out** by such procedure. If the customer is to prepare the test solution is best for him to start well in advance of actual checkout, since for any sizable problem it will take several days or weeks to and calculate the test.

McCracken, D. D. (1957). Program Checkout. In Digital Computer Programming.

Michael Bolton in Why does Kent Beck refer to the "rediscovery" of test-driven development?

rondysousa-blog

Joys and woes of craft

The Joys of the Craft:

Sheer joy of making things

Make useful things that help other people

Fascination of building complex objects of interlocking moving parts and watching them work

Always learning due to nonrepeating nature of the task

Working in such a tractable medium, so readily capable of realizing grand conceptual structures that have real results.

The Woes of the Craft:

One must perform perfectly (one typo and all hell breaks loose)

One rarely sets the objective, provides resources and furnishes information (authority is only acquired through accomplishment of responsibility)

Dependence on others, who may not be performing at same level

Designing grand concepts is fun, finding little bugs is just work,

Debugging has a linear convergence, bugs get harder and harder to find,

Products are usually obsolete upon completion (this is not that bad since the newer better design has the same lag time to realization).

Culture/behavior/mindset follows system & organizational design. i.e., If you want to really change culture, you have to start with changing structure, because culture does not really change otherwise.

Craig Larman in Larman's Laws of Organizational Behavior

By the way, this is an observation in large-scale; in small start ups, it's the reverse: structure follows culture (org design follows mindset).

#software development process

MVP or Minimum Viable Product (...) is about discovering a market for a new product. [To] an organisation with established products and markets (...) MVP means the MVR or “Minimum Viable Rewrite”. The alternative (...) is to consider an MVI or Minimum Viable Investment approach. (...) In effect you refactor your product towards a new vision of the product. If you are building a new product for a new market, use an MVP approach. If you have an existing product (i.e. market), adopt an MVI approach.

Chris Matts in MVP considered harmful. Introducing the MVI.

#software development process

A server like Apache is actually a single webserver that handles a few million connections. In Erlang we create very lightweight processes, one per connection and within that process spin up a web server. So we might end up with a few million web-servers with one user each. (...) On the surface things look very similar. But there is a fundamental difference between having one webserver handling two million connections, and two million web servers handling one connection each. If there is a software error and the server software crashes we lose either two million connections or one depending upon the model. (...) To make a fault tolerant system we use two or more processes per user; One is the master process, the others are replicas on different machines. They must be on different machines since the entire machine where the master runs might crash. We can make it scalable by just buying more machines and spreading the processes out over the machines.

Joe Armstrong in Managing two million web servers

#software architecture

Deployment is a technical event, bits and bytes of software being moved to production servers or users’ devices. Release is a marketing event, where a new version becomes available to a group of end-users. Think about Deployment as the part when an Amazon courier brings a box of cardboard-packed toys, you wrap them up nicely, and hide them in a cupboard. But Release is when your children find the toys under a Christmas tree, at exactly the right moment to believe in Santa Claus. (...) Decouple deployments and releases. This effectively means being able to put software on production systems that is not necessarily generally available, running alongside software that is visible. (...) That way, the marketing stakeholders can decide on their own when they are going to release it and how. Software releases can be organised around important marketing opportunities, while software deployments can still happen frequently to reduce technical risk.

Gojko Adzic in Potentially shippable is no longer good enough

#software development process #continuous delivery

Uncle Bob

Robert Martin (a.k.a. Uncle Bob) in his blog post Giving Up on TDD states that Ian Sommerville gave up too early on TDD.

Conservatism: leads to avoidance of large-scale changes that will lead to the failure of lots of tests

Limit your design options: because you need to design for testability

Too much focus on details: rather than looking at the big picture

Difficulty of large changes due to failing tests, limitation of design options and too much focus on details reveals lack of test design.

Production code should be designed in a way that the tests use the same API as other layers to communicate.

While coding production or test code you should always "Act locally. Think globally.".

Weak data validation: because it’s difficult to think of real bad data

The complexity of creating realistic data has nothing to do with TDD.

#TDD #software engineering

Ian Sommerville gives up on TDD

Giving up on TDD, by Ian Sommerville, author of a popular software engineering textbook.

His reasons:

Conservatism: leads to avoidance of large-scale changes that will lead to the failure of lots of tests

Limit your design options: because you need to design for testability

Too much focus on details: rather than looking at the big picture

Weak data validation: because it's difficult to think of real bad data

#TDD #software engineering

Sometimes a chain of good commits hide a dangerous architecture mistake.

Phil Calçado in How we ended up with microservices

#architecture

Bill Wake's story-splitting strategies

#software development process #requirements

Software systems grow like trees. If you look at any piece of wood you see that it has a grain - a natural direction for growth. The work we’ve already done in code facilitates ease in certain directions. When we think of features that don’t fit the grain, we can create new systems or new areas of code rather than shoe-horning features into current ones.

Michael Feathers in Symbiosis - Implications

#software development process #SOFTWARE QUALITY

(...) in technology we rarely start from zero. The choices we make persist in the software we create. As long as that software exists, it’s organizational memory. It makes some things easy and other things hard. Software isn’t a mechanical thing. In an odd way it’s alive. It grows. When we modify it, it reacts to us. Because of its presence, its value, and its constraints, we react to it.

Michael Feathers in Symbiosis - A Provocation About Organizations

#software development process #software quality

Uber, as we’ve seen, means to be the creative destroyer of the current taxi industry. It bills itself as a way of connecting drivers and passengers. According to this way of thinking, it is primarily a platform and payment system, not a taxi or limousine service. By calling itself a platform rather than a taxi dispatcher, Uber has been able to work in a regulatory gray area that slashes overhead while inflating revenue. This is how Uber can be valued at over $18 billion while many of its drivers make below minimum wage after expenses. Meanwhile, the company’s path to success involves destroying the dozens or hundreds of independent taxi companies in the markets it serves. On the surface, it’s the creative destruction of centralized taxi commissions and bureaucracy. The result, however, is the elimination of independently operating businesses, replacing them with a single platform. Former business owners become Uber’s unprotected contractors. Market pricing and competition are replaced by a monopoly’s algorithmic price-fixing. Creative destruction? Perhaps, but with a twist: **the new businesses of the digital era aren’t stand-alone companies like stores or manufacturers, but, like they say, entire platforms — which makes them capable of reconfiguring their whole sectors almost overnight.** They aren’t just the operators; they are the environment. To become an entire environment, however, a platform must win a complete monopoly of its sector. Uber can’t leverage anything if it’s just one of several competing ride-sharing apps. That’s why we see Uber behaving so aggressively toward its competitors (being accused, for example, of making and canceling calls to drivers of other companies, wasting their time and energy and then advising them to change platforms). It’s not that there’s too little market share to go around; it’s that Uber doesn’t mean to remain a taxi-hailing application. In order to become our delivery service, errand runner, and default app for every other transportation-related function, Uber first has to own ride-sharing completely. Only then can it exercise the same sort of command as the chartered monopolies on whose code these modern digital corporations are still running.

https://hbr.org/2016/03/corporations-werent-designed-to-run-on-code

When Taylor is vilified today, what is he vilified for? It is only two things. First, his approach to determining standards (standard work). He thought standards were best determined by an educated person (an engineer) specifically trained to do this type of job (i.e. time and motion study, with a stopwatch), and that there was “one best way” to do the work. The second was his view towards workers, which seemed harsh due to the words that Taylor used to describe workers in his writings and the manner in which they sometimes curtailed output, called “soldiering” (Ohno called it “waste;” i.e. waiting or idle time).

Bob Emiliani in Lean Hypocrisy

Taylor faced a sellers’ market while Ohno faced a buyers’ market. Taylor was concerned about underproduction while Ohno was concerned about overproduction.

Bob Emiliani in Lean Hypocrisy

#process

Recurring problems with Scrum: - missed commitments / trouble planning and estimating; - estimation and planning are taking too long and seem random, error prone, or just plain nonsensical; - urgent work arrives more quickly than our sprint cadence and there is pressure to reduce the sprint length but we don't know how to do that given the current overheads and the existing problems planning and estimating; - there is pressure to break the sprint boundaries and add urgent work; - product owners show favoritism to one stakeholder over others; - product owners have trouble balancing demands from multiple stakeholders; - stories are being split over multiple sprints and actual customer service is very poor with long lead times and a lack of predictability and transparency; - product owners are suffering anxiety because they are making up numbers to facilitate prioritization and planning activities.

David J. Anderson in Are Scrum and Scaled Agile Damaging Morale At Your Firm?

#software development process