Form is emptiness, emptiness is form.
Being unemployed, I finally have the chance to go to the Philippine Youth Congress in Information Technology (Y4iT) this year.
With the event less than two weeks away, I’ve decided to plan out what I’ll be doing in those four days. Given that the talks will be done simultaneously at the UP Theater and the UP Film Center, I have to decide which talks to attend.
My choices under the cut.
Refactoring is a term you’ll hear thrown around a lot in software engineering discussions. If you’re unfamiliar with the term, you might assume based solely on the content of those discussions that it’s a mystical advanced programming technique known only to experienced developers.
But what exactly is refactoring?
Let’s face it, everyone fails at software estimation including yours truly. It’s probably the least understood part of software development simply because the uncertainties in
This post will not deal with software estimation directly. Instead, it will show you the graphs related to software estimation that you should be familiar with. All of these graphs come from Steve McConnell‘s wonderful book Software Estimation: Demystifying the Black Art; the first group of graphs were copy-pasted from the free Construx presentations while the rest of the graphs were drafted using MS Paint.
While I was going through Rapid Development looking for the backhoe story for the previous post, I came across the graph above.
Looks familiar, huh?
It’s practically the same productivity-to-time graph as the one in the Satir Change Model.
No Silver Bullet tells us to be skeptical about claims of tools that can provide drastic improvements in productivity. What we can instead hope for from productivity tools are minor, yet still significant, improvements.
However, both lowering our expectations and going with proven technologies aren’t enough to receive productivity benefits when introducing a new tool. Many companies still fail because of a certain classic mistake: Lack of Training.