Are your programmers working hard, or are they lazy? When people are doing a physical task, it’s easy to assess how hard they are working. You can see the physical movement, the sweat. You also see the result of their work: the brick wall rising, the hole in the ground getting bigger. Recognizing and rewarding hard work is a pretty fundamental human instinct, it is one of the reasons we find endurance sports so fascinating. This instinctive appreciation of physical hard work is a problem when it comes to managing creative-technical employees.
Effective knowledge workers often don’t look like they are working very hard. Back in 2004, I was a junior developer working in a large team on a cable TV company’s billing and provisioning system. The analogue TV team had decided to base their system around an early version of Microsoft Biztalk. The digital TV provisioning team was very different. The result of all this was that it didn’t look like we were working very hard at all. It's Not A Bug, It's.... We Recommend These Resources When does a bug become a bug? Who decides that it is a bug? How many legs does a lamb have if I say the tail is a leg? The answer is 4, just because I say the tail is a leg does not make it a leg! Bugs should be obvious, but we say It's not a bug, it's a feature because often it isn't obvious. So when does a defect become a defect? When quality assurance tells you that you have a defect? The answer is: none of the above.
This is important because most systems are under specified (if they are specified at all :-) ). Many organizations do not create sufficiently complete requirements before starting development, either because they don't know how to capture requirements properly or because they don't have resources capable of capturing complete requirements. Incomplete (and inconsistent) requirements and unrealistic deadlines often force developers into making decisions about how to implement features. While this process is common, it is destructive. Hours, Technical Debt, and Company Culture | Evan Carmi.
I’ve been thinking a lot about startups, long hours, and excellent company culture. Excellence applied to a product is easily definable. We all know of the products we love and how excellent they are. However, the question of what excellence means for a company is less easily defined. But building an excellent company is as important as – if not more important than – building a successful product. Thus it is something critical to think about as you build a product. You are also building a company and company culture Fundamentally, companies consist of people, and I think excellent companies consist of happy people who productively do meaningful work. Excellent companies have environments where people can be productive.
A productive environment is free of interruptions or other disturbances where people can get work done. Programming is distinct from most other types of work. The brilliant programmer and author Sandi Metz wrote: At every company there are examples of technical debt. Next → Inside Team Romney’s whale of an IT meltdown. It was supposed to be a "killer app," but a system deployed to volunteers by Mitt Romney's presidential campaign may have done more harm to Romney's chances on Election Day—largely because of a failure to follow basic best practices for IT projects. Called "Orca," the effort was supposed to give the Romney campaign its own analytics on what was happening at polling places and to help the campaign direct get-out-the-vote efforts in the key battleground states of Ohio, Florida, Pennsylvania, Iowa, and Colorado. Instead, volunteers couldn't get the system to work from the field in many states—in some cases because they had been given the wrong login information.
The system crashed repeatedly. At one point, the network connection to the Romney campaign's headquarters went down because Internet provider Comcast reportedly thought the traffic was caused by a denial of service attack. As one Orca user described it to Ars, the entire episode was a "huge clusterfuck. " Here's how it happened. Debuggers are for Losers. We Recommend These Resources Code defects are not planned; they are accidents that result from an inability to understand execution flow under different input conditions.
But just as airbags are the last line of defense in a car, a debugger should be the last line of defense for a programmer. Defensive driving reduces or eliminates reliance on airbags. Defensive driving is proactive, it is using all available data to predict and avoid problems. The alternative to defensive driving is to drive inattentively and treat driving like you are in a demolition derby. Situations exist where hardware and software debuggers are essential and have no substitutes. Debuggers will not fix the defect for you Debuggers are not like washing machines where you can throw in your code and some soap, go get some coffee and watch TV, and then 30 minutes later the defect is removed. You can only fix a defect when you understand the root cause of the problem Inspiration, not Perspiration Not There When You Want Them. Google Tech Lead: "Engineering Management Is Dying"
Improve Your Java Development Efficiency with Modelio and UML. Most developers understand productivity as being about producing a lot of code as quickly as possible, because this is their daily experience arising from management and customer pressure. Therefore, many developers think that UML modeling will not increase their productivity by much. They're not completely wrong: drawing a class diagram and filling in attributes and operation signatures is no faster than typing the same information into a class skeleton. Consider the model in Figure 1 and its corresponding Java code, and you'll see that there is not much evidence of enhanced productivity, especially if the Java developer is already using an IDE such as Eclipse. Figure 1 - The simplest model of a Class in UML 01.package customerManagement; 04.import com.modeliosoft.modelio.javadesigner.annotations.objid; 07.public class Customer { The Modelio Java designer module can produce more sophisticated code, depending on the model.
Figure 2 - Association between two classes 06.import java.util.List; Why You Shouldn't Have to Deploy Overnight. Are you still doing deployments at 3:00am? If you are, you should have taken a look at Brian Crescimanno's post: "Why are you still deploying overnight? " Whatever you call the process of turning your development codebase into a live, production application, I sincerely hope you’re not living in the Stone Age and doing it in the middle of the night under the guise of avoiding customer impact.
Unfortunately, if my past experiences, and the experiences of many I’ve spoken to, are the norm, you very likely are. If your strategy to avoid customer interruption is based solely on trying to avoid your customers, you’re setting yourself up for even more headaches and long-term failure. --Brian Crescimanno Brian asserts that if you're doing these overnight deployments to avoid your customers during the initial release, then it's probably indicates that one or more things are broken in your process. Problem 1: You presume there will be problems that impact availability.
How many bugs do you have in your code? If you follow Zero Bug Tolerance of course you’re not supposed to have any bugs to fix after the code is done. But let’s get real. Is there any way to know how many bugs you’re missing and will have to fix later, and how many bugs you might already have in your code? Are there any industry measures of code quality that you can use as a starting point? For questions like these, the first place I look is one of the books by Capers Jones: arguably the leading expert in all things to do with software development metrics.
There’s Applied Software Measurement, or Estimating Software Costs, or Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies. These books offer different views into a fascinating set of data that Capers Jones has collected over decades from thousands of different projects. So what can we learn from Capers Jones about bugs and defect potentials and defect density rates?
Remember that these are rough averages. And as for zero bugs? How horrid software sells and lives - a true (horror) story. Why Code Readability Matters. Lately my colleagues have been commenting on my relentless notes on code styling in our internal code-reviews. Evidently I’ve been paying more and more attention to what could rightly be called cosmetics. Sure there are bad conventions and, well, better ones. Admittedly, coding conventions are just that, conventions.
No matter how much we debate tabs vs. spaces and how much we search for truth, they remain subjective and very much a personal preference. Yet, one can’t deny that there are some better conventions that do in fact improve the overall quality of the code. But code quality is not what worries me. Not as much as worrying about eye strain and accidental misreadings.
Image via Wikipedia Developers don’t write code, not just. Oddly, as I grew in experience I also spent increasingly more time reading code before making additions or changes. The whole issue of maintaining legacy code vs. writing from scratch is a different battle altogether. Consistency. Bugs: Prioritising by Bucket. We Recommend These Resources At a lot of organisations that I've worked there is a tendency to prioritise bugs by a priority bucket. We might therefore have priority buckets 1-4 where the bucket number indicates how important the bug is to fix and then any buckets ranked below 4 would not be fixed but would be logged anyway. From what I've noticed this isn't a particularly effective way of managing bugs. To start with there tend to be a lot of discussions around what the priority of each bug should be where a QA will argue that it should be a higher priority while a developer disagrees.
I'm not convinced that we actually get any value out of these discussions. Another thing that I've noticed recently is that developers are much less motivated to fix bugs if they've been put in Bucket 4 rather than one of the higher priority buckets. I think a better way to solve this problem is just to store whether or not we're going to fix the bug before the next release or not. Freeware for generating UMLs.
When will Software Development be up to Industrial Standards? From time to time I hear people complain, that the Software Development industry is immature. Sometimes they even propose software development should be more like a factory, producing software on some kind of production chain, highly standardized, highly automated. They complain the level of reuse isn’t high enough. I certainly agree, that we have a lot of room for improvement. But the complaints as they are put forward are just proof of total ignorance about how software development works. Reuse in software development is incredibly high. So instead of talking s**t about automation and reuse, let us tackle the real challenges of software development: When every pixel the designer (i.e. coder) changes results in completely different behavior of the product, and when this product is delivered to the customer within days, often hours, there is a high risk of shipping bugs.
We don’t need more automation. The unknown acronym: GRASP. Every once in a while, I find a classic How to be a better programmer post with this mantra repeate in it by a young coder: That's good, and I'm always approving someone that takes the first steps of a personal kaizen and starts improving himself. However, I already tried to go againsta the tide with the How to be a worse programmer article.
Today I'll talk instead of another acronym I never see in this type of posts: GRASP, which stands for General Responsibility Software Patterns (or Principles if you prefer). GRASP is a collection of very high-level patterns (almost only ideas, concepts to keep in mind) for clean object-oriented programming. As such there will be no specific code here, but some principles to adhere. However, I'll include an example of application in each principle definition, since I do not like abstract-level talking about software.
It has been said that "the critical design tool for software development is a mind well educated in design principles. Creator Controller. Håkan Råberg: More than 10 years of Mistakes - Part 1: The Innocent Must Suffer. Part 2 | Part 3 My first professional software development project in the mid to late 90s involved the following, quite lean process: All code was written over ISDN, connected to the production server. Tailing the Apache logs in one terminal, ready to save CGI Perl scripts in the other when activity was low enough on the page you where editing. The first lesson I learned from this was the value of fast feedback. Prior to this I had written software with myself as the primary audience since around age 8, years surely filled with mistakes as well, but at least I was an amateur.
My first idea of how to solve this problem was to edit files locally, having a personal copy of all source. At this point, someone in our team, who may or may not want public credit, introduced RCS on the server. A tool that solves two problems, at once - surely a sign of bad separation of concerns? Here two things happened to me at once.
End User Programming -- Solution or Nuisance? The question of "customization" and "extension" is a common one. For example, "non-technical users to be able to extend with simple scripts". Read this question on Stack Overflow: "Programming / scripting language aimed at non-technical people". This is -- at best -- little more than an attractive nuisance. At worst, of course, it turns into a maintenance nightmare and the reason for killing the project. Let's look at the ways this can end badly. 1. Your "end users" can't or don't customize it with small scripts. 2. 3. "Well," you argue, "those are extreme cases.
War Story I -- The SAS Hacks At one organization, the accountants had created a monster. So they wrote some "simple" business rules in SAS do GL extracts. Our job was to write a proper financial reporting tool that correctly extracted and reported on ledger data. However, because of the SAS hacks, we could not get a single straight answer to any question. Question: How is 9,000 of anything "simple"? No. Why? Bottom Lines. Re-Engineering In Agile Development Can Just Be Refactoring. If you talk to a programmer, almost all software sucks, even the programs they wrote a few months ago. This is typically due to changing technology, increased knowledge or even a market shift.
The software you wrote may have been a good idea when you started, but does it serve the correct purpose now? Even when there is a question of real purpose, the software gets installed into a production environment, because nobody wants to be involved in a project that did not deploy. Now that the system is in production what do you do? Re-engineering is highly problematic from an Agile point of view. Generally, wholesale re-engineering of a system is a bad idea, because the system still serves a purpose and its’ functionality is a moving target. High Defect Rates One way that a technical debt heavy application can present itself is when there is a high defect rate. Replacing Old Technology New Feature Does Not Fit The Design.