"If you adopt economical driving habits, you’ll end up putting less gasoline in your tank.  But if you skip past the economical driving habits and just put less gas in your tank, you’ll end up muttering grim imprecations as you trudge down the highway with a gas can."

"Are you wasting development time polishing things that you don’t yet understand? "

The rapid advances in the field of optimization methods in many pure and applied science pose the difficulty of keeping track of the developments as well as selecting an appropriate technique that best suits the problem in-hand. From a practitioner point of view is rightful to wander "which optimization method is the best for my problem?". Looking at the optimization process as a "system" of intercon- nected parts, in this paper are collected some ideas about how to tackle an optimization problem using a class of tools from evolutionary computations called Genetic Algorithms. Despite the number of optimization techniques available nowadays the author of this paper thinks that Genetic Algorithms still play a central role for their versatility, robustness, theoretical framework and simplicity of use. The paper can be considered a "collection of tips" (from literature and personal experience) for the non-computer-scientist that has to deal with optimization problems both in the science and engineering practice. No original methods or algorithms are proposed.

"Iterative development plans to rework items. Not because they are of low quality, not because they are defective, not because they are unacceptable, but because we chose to limit the scope of them earlier so that we can get to learn something about them sooner. This is a product development technique. Kanban is mainly a manufacturing technique. Software development resembles manufacturing to a degree of approximately 0.0 so it’s a bit of a puzzle why this manufacturing technique has become quite so popular with software developers. Added to which the software industry has a catastrophically bad track record at adopting management ideas from manufacturing in an appropriate way. We in IT are perennial confused about manufacturing, product development and engineering, three related but very different kinds of activity."

"Think of branches in two categories: public and private.

Public branches are the authoritative history of the project. In a public branch, every commit should be succinct, atomic, and have a well documented commit message. It should be as linear as possible. It should be immutable. Public branches include Master and release branches.

A private branch is for yourself. It’s your scratch paper while working out a problem.

It’s safest to keep private branches local. If you do need to push one, maybe to synchronize your work and home computers, tell your teammates that the branch you pushed is private so they don’t base work off of it."

"Now, I don't think there is a way to directly tell git-filter-branch to skip any commits. However, since the commands are run in a shell context, it shouldn't be too difficult to use the shell to remove all but the last X number of revisions. Something like this:…"

'“The artist suggested this: ‘Let’s set a deadline and total budget. I’ll keep you posted on how much is being spent, and of course we’ll have the picture on the wall to look at. By the time we’re about half-way through, it should be of high enough quality, and have enough picture elements, that we could stop any time. You’ll have more ideas, of course, but by then we’ll both have a sense of how fast we can progress, and you can choose the most valuable things to add or change. You’ll have total control over how the picture winds up, and if you want to, we can stop on or before the money runs out.’

“Guido wasn’t entirely convinced. He wanted to know how he could be sure he wouldn’t be left with a horribly ugly wall. The artist told him that she would guarantee to paint it back over and stop any time he wanted, and said she would start by working in some temporary pigment like chalk, so they could erase and change things easily.'

"I find that the big things on the top of the story map look a little like vertebrae. And the cards hanging down look a little like ribs. Those big things on the top are often the essential capabilities the system needs to have. I refer to them as the "backbone" of the software. I stole this term from Dr. Dan Rawsthorne who might use the term slightly differently than I do.



When it comes time to prioritize stories, I don't prioritize the backbone. It just "is." I do prioritize the ribs - the stories hanging down from the backbone. Place them high to indicate they're absolutely necessary, lower to indicate they're less necessary. When you do this, you'll find that all the stories placed high on the story map describe the smallest possible system you could build that would give you end to end functionality. This is what Alistair Cockburn refers to as the "walking skeleton". I always try to build this first."

"Several studies indicate that “old-style” managers are the
biggest obstacle in transitions to Agile software development.
Development managers and team leaders need to learn what their new role is in Agile software development organizations. This course will help them."

"In the midst of a busy project it's all too easy to forget the nuances that distinguish great products. Mental Notes brings together 50 insights from psychology into an easy reference and brainstorming tool. Each card describes one insight into human behavior and suggests ways to apply this to the design of Web sites, Web apps, and software applications."

"The idea part is cheap. Try to think of an idea that’s actually worth something on its own. “I wish I’d thought up the web browser.” Bullshit. The web browser had been thought up at least twenty years before those high-energy frogs coded one up on NeXTstep (c.f. Dynabook, 1968). It was the actual shipping product they wrote that caused the internet revolution, not the idea."

"A story isn't done until it is being used by real users in production and has been validated to be a useful part of a product."

I want this for Ruby, and not in Eclipse.

"Software projects are displayed by Gource as an animated tree with the root directory of the project at its centre. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project."

"Is it possible that if we keep our focus on longer term sustainability, we can still go just as fast in the short term? I believe that it is possible, and that we already have credible evidence that it is possible.

Most of us believe that over the longer term, speed is maximized by operating at a high, but not stupidly high, level of quality. The question is, what is “longer term”?"

"Creating concise commits is probably the most important reason to use rebase, when working in a topic branch I will typically commit every 20-40 minutes. In order to not break my flow, the commit messages will typically be brief and cover only a few lines of changes, atomic commits are great when writing code but they're lousy at informing other developers about the changes.…"

"This seems a reversal of some things I have said in the past about the need for change control. I said that "shit happens" is not an excuse any more. I still believe that. Just because some incidents will remain unpreventable doesn't mean that many others can't be prevented. Just because fixing a problem in one place means higher risks will be taken elsewhere doesn't mean we shouldn't fix the problems. And just because complex systems are impossible to stop breaking doesn't mean that there isn't negligence behind some breakages."

"Don’t you hate when you can’t remove that file full of cleartext passwords from your github account? Even if you git rm it, it still is accessible in previous versions of the tree. So, you need to rewrite the entire tree. Fortunately, this is really easy with git."

"The rest of the items in SEMAT’s proposal are mush. Of course our theories need to address technological and social issues. Of course they need wide support by several communities to be successful. Of course they must be flexible. But what should they consist of? What stake is SEMAT putting on the ground? Unfortunately, beyond a wish to be more like an engineering discipline, this proposal is completely vague, and therefore I cannot support it."

"Simply put, you will not improve unless you strive to get better. You will not improve unless you:
look back on what you accomplished
reflect on what prevented you from doing even better
try to apply lessons learned the next time around
It almost seems so obvious that it's not worth the 15 minutes that it takes your team. But, as anyone that has ever practiced regular retrospectives knows, they are an invaluable tool for identifying group problems that might have otherwise gone unnoticed."

"1. Keep the scope as simple as possible.… 2. Practice ‘Good Enough’.… 3. Kill extra features.… 4. Make it public, quick."

"Scrum set the flywheel in motion and caused the rest of the IT process life cycle to respond. ITIL’s processes still form the solid core of service support and we’ve improved the processes’ capability to handle intense work velocity. The organization adapted by developing unprecedented speed in the ability to deliver production fixes and to solve root cause problems with agility."

"Email is still the easiest way to collaborate with a group of people.
We built tgethr in response to the increasingly complex world of online collaboration. Why set up a project management site or an entire social network when all you need is to correspond by email more efficiently?"

"We're planning a Pivotal Tracker upgrade on Jan 23. As part of this release, we will be introducing a new API version (V3), which will make it easier to follow project activity, allow you to add file attachments, move (re-prioritize) stories, associate source commits with stories, and more."

"The Commission’s resolution also included a call for ODOT to attend their next meeting on February 2 (9 am at City Hall) to discuss the benefits of a bike/ped path included in the bid process. ODOT will release the RFQ that same day, so Brown pointed out that the resolution and alternative technical specification in the RFQ will have to be sent to ODOT this week. ODOT will host a meeting for parties interested in designing the Innerbelt Bridge on Feb. 9. Kuri asked if this was a public meeting (and offered after that a group of advocates might consider forming as a design ‘firm’ to bid on the project – for at least the purpose of attending the Feb. 9 meeting. The guidlines for bidding on the Innerbelt Bridge can be found here.)"

"In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management."

"On a distributed Scrum project, individual team members need to meet each other face to face. If the whole team cannot get together, one or two members from each team, at least, should spend time visiting team members in other cities. Think of them as ambassadors. I’ve found that the personal relationships established by ambassadors can be extremely valuable even long after the ambassador returns to native soil."

"Pick up a document, turn it over and see what’s on the back. If you find diagrams, that suggest the need for clarity as people were drawing on it to explain things."

"How to create your first Personal Kanban and visualize your work."

"The question should not be, “is Rails a safe choice,” but “[how long] can we justify the expense of traditional development approaches.”"

"The service supports multiple GitHub repos and Tracker projects, so you can run a single service that integrates multiple projects. The service will figure out which commits go to which projects based on a config file on the server that associates a GitHub repo URL (make sure to use the http version of the URL, not https), to a Tracker project ID. For example:"

"Synchronize user stories in Pivotal Tracker with Cucumber features."

"Tim's "cool cam" saved European Air War. It went from a money-leaking embarrassment to a top-tier release for MicroProse. The weekly meetings got easier, more developers were brought on, and the team managed to put together one hell of a game. It reviewed well after its 1998 release and is still a popular game for history buffs. And it probably wouldn't have been released if not for a programmer that knew what the project needed most; the cool cam."

Redmine plugins for making the platform more project-appropriate.

"Working in an collaborative environment that simultaneously supports business, technology, creativity, and performance give rise to new concepts. Below we list of some of the ideas we use in our work--terms you may hear or things you may experience if you become a member and spend some time in this unique environment."

"Tracker is a simple, story-based project planning tool that allows teams to collaborate and instantly react to real-world changes. It's based on agile software development methods, but it can be used on a variety of types of projects. Tracker frees you up to focus on getting things done, without getting bogged down keeping your plans in sync with reality."

"We are defined by what we build. It’s not just the engineering ambition that designed these structures, nor the 20 people who died building the Brooklyn Bridge. It’s that we believe we can and decide to act. I’m happy to report our new President agrees when he says,

“In reaffirming the greatness of our nation, we understand that greatness is never a given. It must be earned. Our journey has never been one of shortcuts or settling for less. It has not been the path for the faint-hearted — for those who prefer leisure over work, or seek only the pleasures of riches and fame. Rather, it has been the risk-takers, the doers, the makers of things — some celebrated but more often men and women obscure in their labor, who have carried us up the long, rugged path towards prosperity and freedom.”"

"Retro-Futurist Micro-Scale Anarcho-Syndicalism"

"I have no idea what the interviewer’s expectations are, so I have to guess. I have, essentially, a 50/50 shot at guessing correctly. To make matters worse, my answer will likely go through a number of different interviewers, and I have a 50/50 shot at having guessed correctly with each of them. Assuming that a single “no” from one of the interviewers means I don’t get a job offer, having 2 interviewers gives me a 25% chance of success. Three interviewers gives me a 12.5% chance. A team of 6 or 7 interviewers (extremely common in up-and-coming companies) gives me virtually no chance at all."

"Another common thread in the grad students’ stories was dissuasion, both passive and active, from engagement with the digital. From bureaucratic hassles to tepid advising to being actually barred from computing facilities built for faculty (think about that for a moment; it’s appalling on so very many levels), the message goes out loud and clear: technology is a toy, it’s a diversion, it’s fine for the classroom, but it’s not how you do your work."

"So why is Linux everywhere, and we only hear about 386BSD in historical contexts? There is exactly one answer, and it's what Eric Raymond was really talking about in The Cathedral and the Bazaar. TCatB has been seen mostly as an argument for open-source versus commercial software, but what Raymond saw was that the real competition comes down to an open contribution model versus closed contributions. Linus' promiscuous contribution policy simply let Linux out-evolve 386BSD. More contributors meant more drivers, more bug fixes, more enhancements... more ideas, ultimately. Two people, no matter how talented, cannot outcode thousands of Linux contributors. The best programmers are 10 times more productive than the average, and I would rate Bill and Lynne among the very best. But, as of last April, the Linux Foundation reported that more than 3,600 people had contributed to the kernel alone."

"Here’s what duplication removal does, structurally. It allows you to pull out redundant bits of pulp from big sections, yielding smaller sections, but the side effect is that you end up with more fascia. Duplication removal increases the ratio of fascia to pulp. If the amount of pulp you are able to remove exceeds the size of the fascia you introduce, the net amount of code decreases, otherwise it might increase.

In general, I think that a high fascia to pulp ratio is better for maintenance. It gives us is a higher surface area to volume ratio for our code. This can enhance testability and make it easier to compose new software – we already have smaller more understandable pieces."

[indirect but key]
"Practice, practice, practice!
Don't confuse experience with expertise.
Don't trust folklore -- but learn it anyway.
Take nothing on faith. Own your methodology.
Drive your own education -- no one else will.
Reputation = Money. Build and protect your reputation.
Relentlessly gather resources, materials, and tools.
Establish your standards and ethics.
Avoid certifications that trivialize the craft.
Associate with demanding colleagues.
Write, speak, and always tell the truth as you see it."

"The Depressive Pessimist will complain that the task that they're doing isn't enjoyable, and make statements doubting the group's ability to succeed.

The Jerk will say that other people's ideas are not adequate, but will offer no alternatives himself. He'll say "you guys need to listen to the expert: me."

The Slacker will say "whatever", and "I really don't care."

/replace "design" with "science"/ as well

"Fortunately, we can learn from other fields. Filmmakers operate in a similarly agile fashion, filming scenes in an order dictated purely by logistics. To ensure vision, coherence, and narrative continuity they employ specialists: directors and script supervisors. On the web, designers can play a similar role, but must volunteer and adapt it for themselves. This means getting involved in writing user stories and trying to guide product owners away from over-hasty solutions."

"With these people, there is nothing more offensive than the fork. You are going to split the community, take away committers. It is heresy. It is a schism.

The nature of open source on the SourceForge model is academia at it’s most petty, because the stakes could not be lower. It is not about the source code, it is about the source code repository and control to access thereof.

GitHub puts an end to this nonsense. I can develop my software and I can use GitHub to publish my software. I don’t have to work within an arbitrary community, but grow support for my software through my own social and professional network."

PUBIC BETA

"Strength. Sacrifice. Strongness."

"Successful open source projects combine meritocratic leadership, "doing" more than "talking", and breadth..."

Among other things, testing the ability to bookmark a "related articles" link at Google Scholar.

Formalizing good habits in collaborative workflows

A constant thread in my musing lately: What about the Academy? Can academic research become agile?