Summarizing Mishkin Berteig list of “The Wisdom of Teams - Generalizing Specialists”:

• Backups Team always has a backup specialist, if the assigned one is away, sick, or was hit by a bus.
• Skills Every human being has an incredible capacity for learning. And even more - most of us like to learn new things. By learning even something unrelated to my current major activity, I discover something common and something new that I can bring to happy software development.
• Rules By agreeing explicitly on the expectations inside a team, the team improves cohesion and lowers tension. Better relationships - better software.
• Management Much less management is necessary for such team. In fact, the only real management is necessary is setting up/discussing goals from long term (years?) to short term (end of the week or today) and just giving the team the resources they need. “What can I do for you, team?”

Bookmark to:

No Comments »

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 »

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 »

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 »

Does Bad Writing Reflect Poor Programming Skills?

Writing is a communication skill. And they say that communication skills and the other soft skills are what programmers need today. Effective developers don’t work alone. They work with others in a team. And a team member needs to communicate with the other team members to be effective.

[…]

Writing good prose, and good code, is more about style than about substance. Yes, the substance, the message is also important. But if your style is cluttered and unfocused, no one will grok your message. Your substance won’t matter.

Timothy King gives a deadly good example on communicating with code and comes up with three tips, I’m after:

1. Understand the material before you write.
2. Write as though your audience is a fourth grader.
3. Think about how readers might misinterpret you.

These apply both to documentation, code and chat, as I might say. Even using them I use to restate things several times until my listener catches the idea, so I’d add this too

4. Say the same thing several times in different ways, so at least one of them would be successful.

Bookmark to:

No Comments »

You Scaled Your What?

“We’re embarking on a project to provide us 4X improvement in scalability.”, said the enthusiastic architect.

“Really, in what way?”, I replied, knowing that the trap had already been laid.

“What do you mean, it’s obvious, we will have 4X the scalability of our current architecture when we’re done!”, my com-padre stated with a confused brow.

“Is that transactional headroom, storage improvements, reduction in operations staff, or time to market for new features?”, I offer, struggling to hold back a wry smile.

“Uh, well, I guess it’s transactional headroom, or at least that is what I call scalability.”, he offers, realizing this is probably not going where he wanted.

“Well, can you achieve your 4X scalability if you experience a 4X increase in data volume?”, realizing that I now feel sorry for him.

Yes, this conversation happens far too often. Scaling systems actually require managing the scaling along all of the vectors. Ignore one and that will be the one that becomes your next bottleneck. But what are the vectors? Where is our friend, full of enthusiasm, misguided? Let’s look at the minimal set of scalability vectors that should be considered in every architecture.

The article reviews distinct properties of scalability of an IT business architecture. Dan outlines the following traits:

• Transactional scalability
• Data scalability
• Operational scalability
• Deployability
• Productivity
• Feature time-to-market

He sums this up with a nice spider diagram with an unreadable font, providing visual mapping of those concepts.

Bookmark to:

No Comments »