Chad Fowler on the edge of the years did a great job collecting most of the reasons why “rewrite it” software project fail.

1. Original code is unmaintainable. If it would be otherwise, there would be no “big rewrite”
2. No software requirements documentation.
3. “Use Software as a Spec” also fails .

4. Invention vs Implementation:

   My experience says that most of the time, people doing the Big Rewrite will assume that they’re doing an implementation and will staff and estimate accordingly.

5. Infinite “must be” and “wanna be” features list:

   Imagine going to the hospital for a kidney transplant, and before and during the surgery saying to the surgeon: “Oh, and while you’re already in there digging around, I’ve had some problems with my lungs that could use a little attention. And, yes, I’ve been overeating terribly—-could you do one of those stomach reduction things I hear about? And on that note, how about a little plastic surgery since we’ve got the knives out?”

6. Big Bang release

   But by making it a Big Bang release, you’ve maximized the chances that you’ll be behind schedule when you get to the end, and you’ve therefore maximized the chances that you won’t spend enough time preparing. This results in a bad time for both you and your customers.

7. Justifications for Big Rewrite are too close to lies. And this happens too frequently.

   The piles of justification lead to piles of additional work and/or piles of mismatched expectations and disappointment after release.

8. Existing product frequently coevolves with the “Big Rewrite” version.

The reasons above make any “big rewrite” project to fail, no matter what.

Bookmark to:

No Comments »

KDS Software Group releases development preview snapshot of Py2Py code reformatter.

It is a byproduct of the PyBeast project aimed to create the python mutation tester.

Now Py2Py code reformatter ignores all comments and 80-char line length requirement. Nevertheless, it produces the same AST as the original code.

The code is developed in a test-first manner and has 100% test coverage.

Feedback, criticism and bug reports are welcome.

Bookmark to:

No Comments »

Since it is not possible to predict every detail, every project plan, not just a software development one, needs a feedback loop.

The After Action Review is such feedback link, that was missing in the outline of basic software development process. The third component.

The first two key components are:

• Well Formed Outcome
• Decomposition also known as the “Separation of Concerns”.

Originally it was employer by US Army to adapt to a fast-changing tactics of its opponents. Lately it was incorporated in all army actions and found its way into business.

In simplest form it consists just of four questions, that could be explored either individually or team-wide. These questions are:

1. What was the goal?
2. What are the actual results?
3. Why there is a difference? (Or “Why we were successful?” if no difference)
4. What decisions we can make basing on (3)?

In software development we apply them at every measurable activity step:

• day plan and results
• week plan and results
• milestone
• financial goals

We were surprised how quickly the AAR highlights the open problems in the software project and in the software development process and how quckly and easily we were able to come up with useful and implementable decisions. Decisions that do work and improve the value we bring to a Customer.

It is such simple and powerful tool that not much could be written about it. You have to experience it: try doing daily AAR for at least of couple a weeks.

Apply the AAR and the decisions made rigirously and the world would turn around you.

More information about After Action Review:

• Wikipedia
• US Army’s Leader’s Guide to After-Action Reviews
• Knowledge Management Library,

Bookmark to:

No Comments »

Posts reviewed:

• Don’t make the Demo look Done by The Creating Passionate Users blog
• The Iceberg Secret, Revealed by Joel Spolsky

The bottom line:

How ‘done’ something looks should match how ‘done’ something is.

In more details:

• Customers don’t understand that software isn’t pixels of an user interface. Otherwise they would be programmers.
• Thus showing customers a prototype/mockup/preview sets their expectations.
• Important Corollary One. If you show a nonprogrammer a screen which has a user interface that is 90% worse, they will think that the program is 90% worse.
• Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.
• Important Corollary Five. When you’re showing off, the only thing that matters is the screen shot. Make it 100% beautiful.

Also, take into account that

The more “done” something appears, the more narrow and incremental the feedback.

In other words, to get more general feedback (e.g. about software and UI structure), make it more fuzzy.

See how it works for an html:

• Keeping the cruft out of your release by 37signals
• Matching design sketches to the desired level of design feedback by http://miksovsky.blogs.com

For Java SWIG:

• Napkin Look and Feel

Bookmark to:

No Comments »

Based on RFC 1925. It’s almost verbatim - most of truths are common.

1. It Has To Work.
2. No matter how hard you push and no matter what the priority, you can’t increase the speed of light.
   • (2a) (corollary). No matter how hard you try, you can’t make a baby in much less than 9 months. Trying to speed this up might make it slower, but it won’t make it happen any quicker.
3. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
4. Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in software development can never be fully understood by someone who neither builds an actual custom software product nor administers a such one.
5. It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
6. It is easier to move a problem around (for example, by moving the problem to a different part of the overall software architecture) than it is to solve it.
   • (6a) (corollary). It is always possible to add another level of indirection.
7. It is always something
   • (7a) (corollary). Good, Fast, Cheap: Pick any two (you can’t have all three).
8. It is more complicated than you think.
9. For all resources, whatever it is, you need more.
   • (9a) (corollary) Every software development project always takes longer to do than it seems like it should.
10. One size never fits all.
11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
    • (11a) (corollary). See rule 6a.
12. In software design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

Bookmark to:

No Comments »

Jeremy outlines the basic principles on writing a maintainable code in much more details that I would.

The principal points are:

• software change is inevitable
• planning change with the extensibility points is mediocre
• separation of concerns (see my previous post on decomposition)
• orthogonality

The best ready-to-instant-use thing is Maintainable Code Checklist, which I copy here verbatim:

Question	Yes comes from…
Can I find the code related to the problem or the requested change?	Good Naming, High Cohesion, Single Responsibility Principle, Separation of Concerns
Can I understand the code?	Good Naming, Composed Method, The Principle of Least Surprise, Can You See The Flow of the Code?, Encapsulation
Is it easy to change the code?	Don't Repeat Yourself, Wormhole Anti-Pattern, Open Closed Principle
Can I quickly verify my changes in isolation?	Loose Coupling, High Cohesion, Testability
Can I make the change with a low risk of breaking existing features?	Loose Coupling, High Cohesion, Open Closed Principle, Testability
Will I know if and why something is broken?	Fail Fast

Bookmark to:

No Comments »