Given no information other than the fact that some numerical computations must be performed on each individual target track attribute within your code, which implementation would you choose for your internal processing? The binary, type-safe, candidate, or the text, type-unsafe, option? If you chose the type-unsafe option, then you’d impose a performance penalty on your code every time you needed to perform a computation on your tracks. You’d have to deserialize and extract the individual track attribute(s) before implementing the computations:
If your application is required to send/receive track messages over a “wire” between processing nodes, then you’d need to choose some sort of serialization/deserialization protocol along with an over-the-wire message format. Even if you were to choose a text format (JSON, XML) for the wire, be sure to deserialize the input as soon as possible and serialize on output as late as possible. Otherwise you’ll impose an unnecessary performance hit on your code every time you have to numerically manipulate the fields in your message.
Damn, these are the kinds of bugs I keep finding in my code!
Perhaps it’s time to find a new vocation?
Note: Thanks to @RiczWest for pointing this out to me.
Assume that the figure below faithfully represents two platform infrastructures developed by two different teams for the same application domain. Secondly, assume that both the JAD and UAS designs provide the exact same functionality to their developer users. Thirdly, assume that the JAD design was more expensive to develop (relative depth) and is more frustrating for developers to use (relative jaggy-ness) than the UAS design.
Fourthly, assume that you know that an agile team created one of the platforms and a traditional team produced the other – but you don’t know which team created which platform.
Now that our four assumptions have been espoused, can you confidently state, and make a compelling case for, which team hatched the JAD monstrosity and which team produced the elegant UAS foundation? I can’t.
On the left, we have N collaborating developers, N keyboards, and 1 product code base. On the right, we have the ultimate extension of pair-programming: N collaborating developers, 1 keyboard, and one product code base.
As a developer, which team development approach would you find more enjoyable? As a manager responsible for deciding how to allocate talented people to (hopefully) revenue generating projects, which approach do you think would produce higher quality software at a lower cost?
If you haven’t yet heard about the new rising star in the Agile family of methods, “Mob Programming“, but you find it compelling, here’s the ticket to your next 10X improvement in personal and team productivity:
Mob Programming Certifications (MPC) aren’t available yet, but have patience grasshoppa. They’re coming….
The figure below shows a series of “Grow And Fix” (GAF) cycles that models a software development effort. The gaps between each cycle represent external (to the team) deployment/usage/feedback periods. In practice, there usually are no gaps. After all, any upstanding org filled with managers who are paid to obsess over efficiency can’t allow for any idle machines between incremental releases.
Note that in the GAF way of doing things, the duration for producing a stand-alone increment varies from increment to increment. That’s because the GAF community thinks the act of arbitrarily setting T1 == T2 == T3 == T4 == T (like, say, T == 30 days) for every major increment is a pretty much stupid and dogmatic policy. As stated in the 16 page GAF user guide, the duration for each release is proportional to the breadth and depth of the functionality (f1, f2…. fx) allocated to the release.
In addition to the effort required for defining, creating and integrating new functionality into the growing system, the GAF method takes into account the effort required to “unbreak” existing functionality and to handle emergent, unexpected, behaviors that arise from function-to-function interactions (fix(f1,f2), fix(f1,f3)…).
For more detailed information on the groundbreaking new GAF methodology, including real success stories, endorsements, certification costs, books, T-shirts, hoodies, mugs, and upcoming community conferences, visit the GAF website. Enter the code BD00 at checkout to receive a 10% discount and free shipping on your first purchase.
In six years of blogging, I’ve never reblogged a post… until now. I don’t agree with every point made in this insightful rant, and I outright disagree with several of them, but I resonate with many of the others via direct personal experience.
Originally posted on Michael O. Church:
Follow-up post: here
It’s probably not a secret that I dislike the “Agile” fad that has infested programming. One of the worst varieties of it, Scrum, is a nightmare that I’ve seen actually kill companies. By “kill” I don’t mean “the culture wasn’t as good afterward”; I mean a drop in the stock’s value of more than 85 percent. This shit is toxic and it needs to die yesterday. For those unfamiliar, let’s first define our terms. Then I’ll get into why this stuff is terrible and often detrimental to actual agility. Then I’ll discuss a single, temporary use case under which “Agile” development actually is a good idea, and from there explain why it is so harmful as a permanent arrangement.
So what is Agile?
The “Agile” fad grew up in web consulting, where it had a certain amount of value: when dealing with finicky clients who don’t…
View original 3,303 more words