If we’re doing things correctly, almost everything we write should make the next release or next project easier. Effective reuse taps into the passion developers feel for great code, leading to greater creativity and productivity. Besides, how many Foobulators does one company need, anyway?
As someone who has been around programmers (and ran a Java Users Group) for about 15 years, I often guide senior technologists in marketing their skills. I generally advise my clients on employing some senior level engineers who are strong coders but will also serve a secondary purpose of attracting other less experienced hires.
However, my software developer "build a better mousetrap" instincts took over and I decided to write the report generator myself. But no one used it.
We use the phrase "eating crow" to describe a situation when you must admit that you were wrong after taking a rather strong position about something. While this isn't exactly that case, hence the second title, it does illustrate a lesson in perspective.
Organizations generally go with copying the practices/strategies from other popular brands/companies with the assumption that it works for them. In reality, it won’t.
If you need the same functionality in two projects, you should reuse code between them, right? Or should you? For as long as there has been a profession of software engineering, we have tried to achieve more reuse. But reuse has both a benefit and a cost. Too often, the cost is forgotten. In this article, I examine the economics of reuse.
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (Mar. 14 to Mar. 20). This week's topics include the programmer productivity paradox, the 10 commandments of programming, and 5 tips on how to sell your ideas effectively.
Sometimes proponents of Free Software make it sound as if you must give away all of your code as Free or Open Source Software (FOSS) if you want to be an honest and moral software developer. This is not the case. Morally motivated developers don't always have to give away their software. In fact, sometimes they should not give away their software. Here I explain why by drawing on some basic notions of moral philosophy.
Not all mandates are bad, and some are necessary. Creating such a false dichotomy serves no one in the long term.
Don’t confuse a Shu level implementation of enterprise agile with a by-the-book implementation of Scrum. Your organization may require more advanced mechanisms to implement agile at scale. What you need is one combination of approaches that works consistently while you are getting started.
Failing fast and often is a challenging concept in Agile. It is much easier to state than accomplish. Most individuals have a natural psychological fear of failure. This irrational emotion called Atychiphobia plays a role in life.
I hope this information helps you get started in optimizing your information consumption. As a developer, I’m all about efficiency. And after starting this routine, I’ve been able to regularly digest my favorite online audio content in half the time, which has been a huge win.
This is my third humble strike in the war against the mal-practice of promoting a single model for large scale agile as a one-size-fits-all solution.
In tech especially, we are trained that success hinges on fact. That is probably true, but convincing people to move (even technical people) is as much about emotion as it is about fact. So many people believe that ideas succeed or fail based on the merits of the idea alone. That is not the case.
Agile has indeed become a cargo cult. Stripped of actual software engineering practices and conducted by ‘agile practitioners’ with no understanding of software engineering, it merely becomes a set of meaningless rituals that are mostly impediments and distractions to creating successful software.
In this article the author summarizes, interprets, and re-organizes a list of helpful tips originally created by Darcy Jacobsen.
I’ve started using an approach for software project estimation that so far is proving to be fairly transparent, quick and reliable.
One of the aims of the Agile industry is to enable perpetually cheap refactoring. While we borrow from Lean Manufacturing, we’re going to aggressively repel any attempt to follow regular construction practices.
Programmers seem to be fairly productive people.
f you have decided to join the up-and-coming startup and business founding trend or are already in, then you probably understand that a huge part of your success depends on the right people to work with. In this article, you'll find the job goals the author's company has set for their team developers and designer.
In this article we will be talking about enterprise software and enterprise application. We’ll discuss topics such as development of these applications and software that corporations will need.
The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context?
Turing assembled the entire Geek community and said to them, "These are the things that the Compiler has commanded you to do:"
All ops teams share the need to meld an interruptive work stream with a planned one, and it’s hard to get that right. In the Site Services team in Site Engineering at New Relic, we have a Kanban process that we use to manage our workflow. We’re pretty happy with how it’s working for us, so in this post I’ll share what we did and why.
Today I will discuss scaling retrospectives. While the scaling discussion is receiving a great deal of press in the agile world these days, we have overlooked the retrospective area in my opinion. Time for a change: