Would you rather be known as the person who does a lot of stuff that is almost right? Or the one who nails every deliverable?
If you want a vibrant and dynamic engineering culture, standing desks are a must. I view them as fundamental to a programming team as decent workstations and SSDs.
Critical decision-making meetings can easily run off the rails when many key stakeholders are present. Here are 7 ways to guarantee yours will fail.
Parkinson's Law says that "organizations give disproportionate weight to trivial issues." This statement later became known as Parkinson's Law of Triviality, or PLOT. Although Parkinson was referring to organizations as whole, over the years this problem has become a pervasive issue in software development.
Technology changes have moved developers, previously of little importance within the world of IT, to a central direction-setting role within companies.
I spoke with Dave West (Chief Product Officer at Tasktop, former analyst at Forrester Research, hyper-guru on all aspects of ALM), about all aspects of the software development lifecycle, with some emphasis on how good software engineering can shorten cycle times and avoid technical debt.
In early April I received a message from Ben, delivered to my Reddit account.
Firing brilliant jerks is the absolute worst thing to do for teamwork, or indeed the health of the company as a whole.
All managers want employees with excellent development and organizational skills, but when forming an Agile team, talent alone won’t cut it.
It can be an underlying reason individuals at the team level are resistant to an agile adoption. There are a number of ways to “solve” this problem.
Good testers have the wonderful skill of asking “What if I do this”? This thinking is different than “happy path” coding, where we “know” the answer. People with experience in TDD develop this skill as well.
False projects occur when we use the word “project” for work which is not really a project. Some might think I’m playing word games here but I think its important, I think we need to be clear about our terms. Please, hear me out.
I was always comparing software development with engineering ( building bridges, building etc. ) and it looked quite a straightforward compariso
Unit testing pre-dates TDD but TDD reverses the idea of testing your units of code and says you should start with a test, and that test should fail, and then you should write the code to make the test pass.The obvious advantage to this is that when you subsequently make a change you can see if the change has broken anything else in the system, which will give you greater confidence in your code.
The elements needed to build a successful, mature software development team can keep most managers up at night. Without it, the programming suffers and it can ultimately influence the success of a project/product.
This is a quick note about an idea I’ve been using with a few software teams during the last couple of years. Tl;dr — don’t guess the size of a story; fit the story to the size you want.
All agile ceremonies should have very clear objectives and outcomes. When we work with new agile teams we make sure they understand the ceremonies of scrum and other agile meetings necessary to deliver value.
This management myth is something I see often in organizations. This one is the one where people are running around so often they don’t actually solve problems.
I have been developing software professionally since 1978. I went to law school (BU Law '91). I think that computer programming technology and the law are really, really similar.
Hot on the tail of my previous post about language popularity, the latest numbers from the TIOBE are out. The top five languages are C, Java, Objective-C, C++ and Visual Basic. Every other language beyond that has less than 4% mind share.
When we are in flow, we are at our most productive. Not only do we work quickly but we make effective decisions. In flow, hours can go by in a blink of an eye. You’ll look up and marvel at what you’ve accomplished!
Following Hakuna Matata or always striving for perfection are two very different ways of living your life. In the short term Hakuna Matata (which means “No Worries”) looks tempting, but there’s also happiness to be found in the strive for perfection through a continuous improvement mindset.
A Scrum Master really is supposed to be the person who clears the path for the team so they can run as close to full speed as possible. The Scrum Master is sort of like the pit crew for a race car driver.
Running into challenging situations or problems is a fact of life in software development. From complex coding constructs to tricky phantom bugs, programmers spend many hours traversing their own minds in search of the right answer. At times the problem seems obvious, while on other occasions, it seems to hide behind a subtle impenetrable veil. Sometimes on these occasions, without provocation, the solution arrives like a rushing tidal wave. Why is this?
Scrum and Kanban lead to the evolution of Scrumban. Combine the two approaches and receive a sum that is larger than its parts. When implementing Kanban it stipulates to "respect the current process, roles, responsibilities, and titles." This lends itself to simple integration with existing systems; furthermore, Scrum and Kanban both champion continuous process improvement and self-organizing teams. The big question is, "Can these two ideas coexist?"