Jazoon 2012: Why you should care about software assessment

28. June, 2012

Tudor Girba gave a presentation at the Jazoon about a topic that is very dear to him: Software assessment. To quote:

What is assessment? The process of understanding a given situation to support decision-making. During software development, engineers spend as much as 50% of the overall effort on doing precisely that: they try to understand the current status of the system to know what to do next.

In other words: Assessment is a process and a set of tools to help developers to make decisions. They typical example is a bug shows up and you need to fix it. That raises the usual questions:

  1. What happened?
  2. Why did it happen?
  3. Where did it happen?
  4. How can I fix it?

As we all know, each of these steps can be difficult. As an extreme example, someone mentioned selling software to the NSA. It crashed. The NSA calls the developer:

NSA: “There is a problem with your software.”

You: “Who am I talking with?”

NSA: “Sorry, I can’t tell you that.”

You: “Well … okay. So what problem?”

NSA: “I can’t tell you that either.”

You: “… Can you give me a stack trace?”

NSA: “I’m afraid not.”

Unlikely but we all know similar situations. Even seasoned software developers are guilty of giving completely useless failure reports: “It didn’t work.” … “What are you talking about? What’s ‘it’?”

Tudor gave some nice examples how he used simple assessment tools that allow him to query log files and sources of some application to locate bugs, locate similar bugs and help to find out why some part doesn’t behave well. Examples:

  1. An application usually returns text in the user’s language but some rare error message is always in German. Cause: When the error message was created, the code called Locale.getDefault()
  2. Several other places could be found that showed the same behavior by searching the source code for places where Locale.getDefault() was called either directly or indirectly. A test case was added to prevent this from happening again.
  3. Some cache would have a hit ratio of less than 50%. Analyzing the logs showed that two components used the same cache. When each got their own cache, the hit ratios reached sane levels.

So assessments allow you to do strategic planning by showing you all the dependencies that some part of the code has (or the whole application).

In a spike assessment, you can analyze some small part to verify that a change would or could have the desired effect (think performance).

Did you know that developers spend about 50% of the time reading code? If tools can help them understand some piece of code faster, that makes them more productive. Unfortunately, today’s tools are pretty limited when it comes to this. Eclipse can show me who calls Locale.getDefault() but it can’t show me indirect calls.

Worse: If the developer makes the wrong decision because she couldn’t see all the important facts, then these often have a huge impact.

Another important aspect is how you use metrics. Metrics are generally useful but the same is not true for every metric. Just like you wouldn’t copy unit tests from one project to the next, you need to reevaluate the metrics that you extract from each project. Some will just be a waste of time for certain projects.

My comments:

We really, really need better tooling to chop data. IDEs should allow me to run queries against my source code, collect and aggregate data and check the results in unit tests to validate design constraints.

It was also interesting to see how Tudor works. He often uses simple words which can be misleading. But when you look at the slides, then there was this graph about some data points. Most graphs show a linear Y axis with the ticks evenly spread. He uses a different approach:

Usual diagram to the left, Tudor’s version to the right

Related links:

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

Jazoon 2012: Development Next – And Now For Something Completely Different?

28. June, 2012

Dave Thomas gave the keynote speech (link) about how technology seems to change all around us just to show up the same, old problems over and over again.

Things that I took home:

  • In the future, queries will me more important than languages
  • Big data is big

Some comments from me:

How often were you irritated by how source code from someone else looked? I don’t mean sloppy, I mean indentation or how they place spaces and braces. In 2012, it should be possible to separate the model (source code) from the view (text editor) – why can’t my IDE simply show me the source in the way that I like and keep the source code in a nice, common format? (see Bug 45423 – [formatting] Separate presentation from formatting)

And how often have you wondered “Which parts of the code call Locale.getDefault() either directly or indirectly?”

How often did you need to make a large-scale change in the source code which could have been done with a refactoring in a few minutes – but writing the refactoring would have taken days because there simply are no tools to quickly write even simple refactorings in your IDE?

Imagine this: You can load the complete AST of your source code into a NoSQL database. And all the XML files. And the configuration files. And the UML. And everything else. And then create links between those parts. And query those links … apply a piece of JavaScript to each matching node …

Customers of my applications always want new business reports every day. It takes way too long to build these reports. It takes too much effort to change them. And it’s impossible to know whether a report is correct because no one can write test cases for them.

Leave a Comment » | Conference, Software | Tagged: , , , | Permalink
Posted by digulla

If You Want Them to RTFM, Make a Better FM

16. May, 2012

If you’re interested in the conflicts between software and documentation, Alex Lagarde wrote a great post about that: Intent Discovery – Part 1 : the intents behind softwares.

It explains what the different (and conflicting) goals are between the “technical space” (source code), “model space” (design and architecture) and “document space” (what people need to use the software successfully). And he promises some solutions with the new Eclipse project “Intent” (and the second post in the series).

2 Comments | Software | Tagged: , , , | Permalink
Posted by digulla

Making Daily Stand Up Meetings More Effective

16. March, 2012

Are you doing daily stand up meetings? Feeling like you’re wasting your time?

It’s Not Just Standing Up: Patterns for Daily Standup Meetings might help.

From his post:

The daily stand-up meeting (also known as a “daily scrum”, a “daily huddle”, “morning roll-call”, etc.) is simple to describe:

The whole team meets every day for a quick status update. We stand up to keep the meeting short.

That’s it.

But this short definition does not really tell you the subtle details that distinguish an effective stand-up from a waste of time.

More…

Leave a Comment » | Software | Tagged: , , | Permalink
Posted by digulla

Commenting Code

1. March, 2012

A lot of people way “you must comment your code.”

Kevlin Henney wrote an excellent piece on this topic in 97 Things Every Programmer Should Know: Comment Only What the Code Cannot Say

It really boils down to the last sentence: “Comment what the code cannot say, not simply what it does not say.”

There are various reasons why people demand comments:

  1. They are not fluent in the programming language or don’t know enough to read the code. There is nothing wrong with the code – the readers simply don’t know enough to understand it.
  2. The code is broken in some way and you need the comment to make sure people don’t break it even more.
  3. The comment explains something that no one will see from the code.

Only #3 is a valid reason for comments. #1 is just adding noise for people who shouldn’t touch the code anyway. #2 means you should refactor the code to make its intent clear – adding comments will only make things worse.

Related articles:

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

Code Is Design

22. February, 2012

If you look for reasons why software development is often such a mess, here is an interesting, new angle: Code Is Design by Ryan Brush.

Leave a Comment » | Software | Tagged: | Permalink
Posted by digulla

New Years Resolution: Stop being so agreeable!

30. December, 2011

How quick are you to say “sure, we can do that”?

Here are a couple of reasons to reconsider your attitude: Stop being so agreeable! by Erick Erickson.

Leave a Comment » | Philosophy, Software | Tagged: , | Permalink
Posted by digulla

Do You Know Your Limits?

17. October, 2011

This interesting talk by Dan Ariely – Are we in control of our own decisions? – got my thinking. Dan says:

We understand our limitations. And we build around it. But for some reason when it comes to the mental world, when we design things like healthcare and retirement and stockmarkets, we somehow forget the idea that we are limited. I think that if we understood our cognitive limitations in the same way that we understand our physical limitations, even though they don’t stare us in the face in the same way, we could design a better world.

(my italics)

I think that is a very important point. Software development is a purely mental process. We take ideas, translate them into code. We’re authors, our audience is a CPU. We write in RAM chips instead of on paper. But basically, we’re translators.

Most software developers know their tools but not their own mental limits. Ask yourself: How much brain power does it take to type on a keyboard? Got your number?

It’s about 30%. When you type yourself, you only have 70% of your brain left to think what you’re typing.

Software development is a craft but it’s not like smithery. We had anvils and fire pits at my school. When you work with yellow-hot glowing steel, a five-pound hammer and an anvil, you learn something with your first strike: This is dangerous, this is hard work, this isn’t as simple as it looks, and how fast you’re going to tire.

How do you do that? Because your brain is wired by millions of years of evolution to know such things. Your muscles are designed to give you feedback: Can I outrun my enemy or do I have to make a stand? Forging steel is built into us. The result will vary with clumsiness but every person in my class was able to hit the steel with a hammer. It takes a day to teach someone to write the most simple program in Java but it takes one sentence to teach them how to flatten iron: “Take one of those hammers and hit it here.”

If driving steel is so simple, why are we so bad at software development?

Well, it’s one of those tasks where one brain tries to achieve two conflicting goals: Write software and at the same time watch itself doing it right. It’s a dilemma. You have 70% tops unless you have trouble at home, worry for your job, are hungry or mad at the guy next door yelling in his telephone. How much of the 70% are you going to give to “write software” and how much to “do it right”?

That said, being a software developer, you’re male (98% chance). Males suck at doing two things at a time and you’re already doing at least two. How much good is adding control to the pile going to do?

Probably not much. So what can you do?

First: Don’t forget that you’re limited. Clear your brain. Heed your limits.

Second: Turn your limits into a foundation. Instead of struggling with them, accept them. Use techniques like Test Driven Development to do one thing at a time: Tests answer the “do it right?” part. When you have the test, you can forget about this and go the “write software” part.

Use you limits. They are tools just like everything else.

Leave a Comment » | Uncategorized | Tagged: | Permalink
Posted by digulla

Why Writing Software is Not Like Engineering

12. September, 2011

Excellent article by Terence Parr: Why writing software is not like engineering

Main points:

  • “Congress does not go to NASA halfway through a moonshot and ask them to go to Mars instead.”
  • When building a house, it’s pretty hard to make the toilet flush when you ring the doorbell. In languages like C++, it’s very hard to make 100% sure this can’t happen.
  • Is it science? No, science is about conducting experiments and accumulating knowledge.

I don’t agree with software == art. Art is meant to make emotions available to a larger audience. Maybe writing error messages at M$ is an art form but general coding isn’t.

Conclusion: Software development is a craft just like carpentry or masonry.

Related articles:

1 Comment | Software | Tagged: | Permalink
Posted by digulla

Final Java Questions

3. September, 2011

Recently, I read a blog post which talked how “stupid” today’s developers are. As an example, “the interviewed candidates claims that they are very good at core java and saying that we can’t add/remove elements to an ArrayList which is declared as final.” (Are Frameworks Making Developers Dumb?)

Funny, right? But it got me thinking.

How important is it really that someone knows this? With over 60K points on stackoverflow, I’m one of the most knowledgeable software developers in the world but there was a moment, when my brain stumbled over the question. I rarely use final in my code. So how much value does this information have? How often do I need this every day? Once per week? Month? Year? How much damage can the wrong answer cause?

While I agree that sound knowledge helps a lot, I see team mates struggle much less. They don’t know as much as I do but there is a demotivating effect here: If you know too much, every simple question triggers a flood of thoughts: What can go wrong? Didn’t we encounter this already? What’s the best solution?

Sometimes, there are two “best” solutions and missing any further input, I can get stuck in a deadlock. Which way to go?

Or the solution to a problem triggers a new problem which in turn triggers a third. Suddenly, I’m caught in a maelstrom of dread which overwhelms me: Every possible way out just causes more trouble.

So for me, knowledge isn’t everything. Some people are “just” decent developers but that should not stop you to hire them. Here are some other, valuable factors:

  • How easily do they give up?
  • How well do they play as a team? That doesn’t mean everyone has to be a “team player” (whatever that might be). But strengths and weaknesses of each individual should compensate each other. One guys likes to talk a lot, let him handle customers. The other guy likes to work alone, give him the hard tasks that need a lot of time and concentration.
Most of all, make sure that every member of the team understands that a weak spot doesn’t make someone less valuable. It just makes them less valuable for certain tasks. If you can distribute the tasks just right, the team will be much stronger than one made up from the best developers in the world.

Leave a Comment » | Philosophy | Tagged: , , | Permalink
Posted by digulla

« Previous Entries
Next Entries »