One of the misconception that is often associated with agile software development is that agile teams won’t write any technical documentation. I assume that this misconception is so common because the agile manifesto states that we should value
There was a time (not so long ago) when we designed everything before we wrote any code. We gathered the requirements of our application and wrote the requirement specification. We took these requirements and designed an architecture that helped us
Yesterday I published the list of the most popular blog posts that I wrote in 2014. I also promised to choose my favorite blog posts and publish that list on my blog. This year I decided to select blog posts that helped me to learn something new.
I have always thought that I am good at multitasking. That is why I believed that I don't have to pay the price associated with context switching (or task switching). This week I realized that have been wrong. I am not very good at multitasking and
This week I read a blog post titled Where is the Foreman by Robert "Uncle Bob" Martin. It made me think. Uncle Bob suggests that a software development team should have a foreman who: He'd make sure everything was done, done right, and done on time.
When potential customers contact us, the odds are that they want to know two things: How much does it cost to implement the application? How long it will take to implement the application? The honest answer to both of these questions is: We have no