Slashdot Mirror

All sound great in theory, fall apart in practice, and there will always be someone who says, "You just didn't implement it the right way!"

Agile is not communism.

Exercising sounds great in theory, falls apart in practice, and there will always be someone who says, "You just didn't implement it the right way!"

Eating healthy sounds great in theory, falls apart in practice,...

Just because a thing is hard to do or commonly not done well does not mean that the thing itself is bad, wrong, or irrelevant.

This might be interesting for people: Enterprise Agility - Pragmatic or Transformative.

Two articles that I wrote about this:

The Software Construction Analogy is Broken

and

Technical Push-Back

I don't have a lot of patience with the profession since it's built on a fatally flawed analogy and all software architects ever do is waste and overhead from a lean perspective.

Here is an article I wrote a few years about about this. Probably helpful: http://www.agileadvice.com/2012/01/08/scrumxplean/seven-options-for-handling-interruptions-in-scrum-and-other-agile-methods/

"... the successful functioning of the IT department shouldn't rest on any one person's shoulders.". This is know as "Truck Factor". http://www.agileadvice.com/archives/2005/05/truck_factor.html

Here is the reply from the author of the originating article: Dmitri Zimine.

what strategies should a developer take to insure that the resulting program is as crash-free as possible?

Simple, easy answer: unit test it as much as possible, then tinker with the design to make more unit tests posible.

Beyond that, do regular code reviews and get into the habit of programming defensively.

this applies to any language, not just C++. There's even a port of JUnit to C++ over here

The qualities of an ideal test is a framework similar to ACID for databases and INVEST for user stories. It describes six verifiable qualities that a test should have. On a related note, this article doesn't make me really that excited. I've been using test driven development with JUnit and NUnit to deliver tens of thousands of lines of code into production with similar defect rates (about two defects found over the course of several years of code being in production). I maintained good productivity rates, delivered code into QA with no defects found, into pre-production with no defects found and finally into production where defects were found only after a great deal of time in operation. The code was not simple either: it was asynchronous, guaranteed delivery, multi-threaded messaging code for enterprise systems. Developers who don't do TDD should be paid about 1/4 as much as developers who do, IMNSHO.

Profit sharing would be more effective because it motivates on both the cost and the revenue side of things. If the team feels like it can't directly contribute to improving sales (revenue), then perhaps they will be motivated to reduce costs. In order for this to work, the company cannot use a command-and-control method of management. Individuals must be given leeway to independently take action to make improvements. If these two things aren't in place then it will all just lead to apathy and cynicism. I suggest checking out lean software development and agile software development resources. My sig contains a good starting point, but it is more management oriented. I also have a couple of articles about metrics in particular. This article about metrics is good.

This is a complex problem. First off, funding for institutions of higher learning comes from a multitude of sources. Colleges need to attract funding and in order to do that they need to attract students. In order to attract students, they need to create programs that are attractive to students. In Canada, colleges and universities are publicly funded and their funding is largely based on the number of students. This competition for students is unfortunate because students who are 19 years old tend to be relatively short-sighted about what constitutes a good education.

Secondly, I believe almost any course of study can become excellent education depending on the teachers/instructors/professors. My father is probably the best professor one could ever have: his background as a professional fine artist combined with experience in education and volunteer activities, plus his interest in philosophy and science makes him singularly capable of delivering an excellent course regardless of the subject matter. He is constantly creating new and better methods of instruction for his courses that he teaches at Keyano College. Incidentally, he has been investigating the creation of a game design program at the college... because it is cutting edge in terms of the arts!

I personally strongly feel that if I had focused on a purely technical or vocational path in my education I would not be nearly as far along in my career as I am. I studied sociology, philosophy, anthropology, linguistics, French, Russian, marketing and accounting in addition to my core computer science and mathematics classes. The benefits of these classes have become clear 15 years later as I am doing management consulting for Agile methods. If a program is going to be about game design, make sure that it includes a diversity of relevent subject matter such as gender studies, theatre, story-writing, linguistics, adult educational theory, etc. in addition to the technical stuff.

Check out Microsoft Takes it on the Chin Over Test-Driven Development. For comparison, check out Wikipedia on Test-Driven Development. This is particularly ironic given the recent Slashdot article about Microsoft adopting Scrum, one of the agile methodologies which, along with Extreme Programming, is instrumental in promoting Test-Driven Development as a core software engineering practice. I've also got a very brief article on my blog about the Qualities of an Ideal Test.

Lots of related concepts around agility, management, teamwork, prioritization, queues, lean, adult learning, coaching, testing etc. all can be found on the blog Agile Advice - How and Why to Work Agile - The Middle Way to Excellence. If you like this chapter, I think you will enjoy a good portion of the entries on that site. I run the blog and I am the primary contributor, but there are a few other regular contributors as well and I have recently opened up a Guest account for anyone to contribute articles. (Yes, I know, a dangerous thing :-).

• POHtml/css: ultimate in flexibility for layout and publishing. Pain in the butt to update and maintain.
• Movable Type: good balance between flexibility, built-in dynamic features and maintainability. Irritating to keep up-to-date for software versions, and a little slow for some of the dynamic features.
• Blogger: easiest to use by far. Nice integrated anti-comment-spam. Not very flexible in comparison.

Using automated unit test frameworks such as JUnit is one of the most important engineering practices in the whole suite of agile practices. Many agile practices that don't explicitly ask for test-driven development still will insist that Agile is enabled by technology that allows for fluid, testable work. I'm very interested in Agile applied outside of software, and the underlying principles and practices of Agile. The situations where it can apply best have some sort of technological support for automation, and in particular automation of tests. I have seen situations where spending >$50,000.00 to build a custom automated test harness is money well spent in order to avoid mistakes in the first place. One of the main principles of Lean (a heavy source of influence for Agile), is that you can only go fast if you have exceptionally high quality. Any source of defects slows a project/team/production line down.

Using automated unit test frameworks such as JUnit is one of the most important engineering practices in the whole suite of agile practices. Many agile practices that don't explicitly ask for test-driven development still will insist that Agile is enabled by technology that allows for fluid, testable work. I'm very interested in Agile applied outside of software, and the underlying principles and practices of Agile. The situations where it can apply best have some sort of technological support for automation, and in particular automation of tests. I have seen situations where spending >$50,000.00 to build a custom automated test harness is money well spent in order to avoid mistakes in the first place. One of the main principles of Lean (a heavy source of influence for Agile), is that you can only go fast if you have exceptionally high quality. Any source of defects slows a project/team/production line down.

Using automated unit test frameworks such as JUnit is one of the most important engineering practices in the whole suite of agile practices. Many agile practices that don't explicitly ask for test-driven development still will insist that Agile is enabled by technology that allows for fluid, testable work. I'm very interested in Agile applied outside of software, and the underlying principles and practices of Agile. The situations where it can apply best have some sort of technological support for automation, and in particular automation of tests. I have seen situations where spending >$50,000.00 to build a custom automated test harness is money well spent in order to avoid mistakes in the first place. One of the main principles of Lean (a heavy source of influence for Agile), is that you can only go fast if you have exceptionally high quality. Any source of defects slows a project/team/production line down.

I've written up a brief introduction to the qualities of an ideal test. The great thing about unit test frameworks such as JUnit, NUnit, CPPUnit, etc. is that they manage to satisfy all of these qualities: Decisive, Valid, Complete, Repeatable, Isolated and Automated. (Although it is possible to break some of these qualities with poor test creation practices.)

One of the common anti-patterns is over-relying on tools and frameworks instead of inventing new programming models.

Actually, he missed the anti-pattern. It's really: One of the common anti-patterns is over-relying on tools and frameworks and programming paradigms and processes instead of improving the skills and knowledge of the people doing the programming.

I've been programming for a long time too, and I don't think that new programming models do all that much for productivity compared to finding good people or investing in improving the people you have. The recent Joel on Software article discusses this at length. This is one of the big reasons I'm so interested in agile methods and principles.

Managing for creativity requires deep recognition of the fact that people are creators. Not only that, but the constant change of circumstances should be embraced as a fertile ground for creativity. And finally, it is very important to realize that the way people perceive reality is critical to them being empowered to be creative... and for their contributions to be valued. I write about this kinda stuff all the time - hopefully in a predominantly practical way - on my blog: Agile Advice.

My Agile Advice blog is all about this. Basically - how do you go between chaos (caused for example by really smart people with no direction), and bureaucracy (caused for example, by people who know what needs to be done, but don't have a clue how to do it).

(* Blatant Self Promotion - but blog has tons of great info and concepts and is not directly commercial)

people do

That is why until organizations learn to ignore their big huge engineering-based waterfall processes and start focusing on developing their people both individually and as teams, they will not see any significant improvements in their ability to use IT more effectively. Agile methods are really great because they turn the focus away from the process (use the minimum process that can possibly work), to the people (teamwork, communication, collaboration, mentoring, etc.). That isn't to say that agile methods are easy... far from it. In many cases it takes a huge cultural shift for an organization to adopt agile methods. However, the effort is worth it because suddenly projects that used to take 18 calendar months are being finished in 4 or 6 calendar months... simply by eliminating the worst wastes in the corporate system, amplifying the team's learning, and allowing them to make decisions about how they do their work.