Archived Posts from this Category
Archived Posts from this Category
Summarizing Mishkin Berteig list of “The Wisdom of Teams - Generalizing Specialists”:
Chad Fowler on the edge of the years did a great job collecting most of the reasons why “rewrite it” software project fail.
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.
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?”
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.
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.
Existing product frequently coevolves with the “Big Rewrite” version.
The reasons above make any “big rewrite” project to fail, no matter what.
The bottom line:
How ‘done’ something looks should match how ‘done’ something is.
In more details:
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:
For Java SWIG:
Jeremy outlines the basic principles on writing a maintainable code in much more details that I would.
The principal points are:
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
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:
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.
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:
He sums this up with a nice spider diagram with an unreadable font, providing visual mapping of those concepts.