Jazoon 2013 – 33 things you want to do better

25. October, 2013

Jazoon 2013 badgeTom Bujok listed a lot of methods, technologies and frameworks that you should be aware about in his talk “33 things you want to do better” (slides on speakerdeck)

At the beginning he reminded us how quickly a well designed system goes bad due to hurried changes. We need to be aware of our technical debt and we need to allocate time to spend on reducing it (slides 3-12).

As an example, car batteries are easy to find. They are a replacement part, designers and engineers make it easy to find. Compare this to the configuration of your project. If you need to change it, how easy is it to find the file that needs to be changed and then the place in the file?

Another important point is skills. In most other professions, you have some mastery of a skill before you use it. You train hundreds of hours before you play your first football game. In Software, we show you a computer, we show you the programming language of the year (not necessarily this year’s). There is no time to master the tools you have to use from day one (slides 13-15).

“We are what we repeatedly do; excellence then, is not an act but a habit.” – Aristotle

Or as Wikipedia defines it:

“Habits [...] are routines of behavior that are repeated regularly and tend to occur subconsciously.”

Stop wondering why you always make the same mistakes – they’re habits. Eliminate them ASAP (slide 19):

Bad Habits – Katherine Murdock “The Psychology of Habit”:

  • Recognize bad habits and eliminate them ASAP
  • The older you get the more difficult it is to remove a bad habit
  • Each repetition leaves its mark!

Turning bad habits into good ones – Dr. Michael Roussell, PhD.:

  • You can’t erase a habit, you can only overwrite one.
  • Insert the new habits into the current habit loops

Bad Habits

Configure your IDE properly and remove bad defaults. Replace “ex.printStackTrace();” with “throw new RuntimeException(ex.getMessage(), ex);” (slides 43-45).

One bad habit is empty catch blocks with “can never happen” comments. If you see one during a code review, replace it with “System.exit(-1);”. It can never happen, right? Right? (slides 46-47).

Note: I have create a “ShouldNotHappenException” for this case :-)

Another one is to make every method in a static helper class public. Maybe some of them can be package private? (slide 48)

Learn about other good habits. Read books like “Effective Java” (Joshua Bloch) and “Clean Code” (Robert C. Martin) (slide 49)

Use code reviews to notice bad habits and to spread knowledge in your team but prevent blame games. (slide 73)

Learn the keyboard shortcuts of your IDE (slide 78)

Remember (slide 79):

“Any jackass can kick down a barn, but it takes a good carpenter to build one.” – Sam Ryburn

Projects You Should Know

Project lombok and lombok-pg - In a nutshell, these hook into the Java compiler and generate additional bytecode when certain annotations are present. Bored with getters, setters, hashCode() and equals() plus a nice toString()? Use @Data (slides 21-28).

Guava (slides 29-33)) is a great library with many tools that you have been missing in Java for years. You might also want to look at commons-lang.

Want to use lambda expressions but can’t upgrade to Java 8? Then lambdaj is for you (slides 34-39).

Logging? slf4j (40-42). Especially nice when combined with the @Slf4j annotation from lombok.

Bored to write all that boiler plate code to create all those services and managers that form your app? Look at Guice or Spring.

Use Spock to make tests more compact and easier to understand. (slides 50-52)

Unitils contains all the helper functions that we always missed in JUnit and Hamcrest (53-56).

JUnitParams will help you run tests with different parameters (57-59).

Need to wait for something during a test? Awaitility will help. (60-61)

When mocking isn’t enough and you need to inject code during a test, Byteman is the tool you want to look at (62-63)

Getting bored writing boiler plate code in Java to make a compiler happy? Have a look at Groovy. (64-67)

How about adding dependencies to your scripts? Try Grape. (68-69)

Is your build a mess? Do you feel Maven is too verbose or too limiting? Gradle might be for you. (70-72)

Version control is slowing you down? Have a look at Mercurial or Git (75)

Use bash or Python to automate man-/menial work. If you’re on Windows, look at Babun or Cygwin. (76-77).


Quick: How Does Quicksort Work?

24. June, 2013

Every now and then, we need to remember how some complex algorithm works. For some, code works well. Or puzzles. Others prefer an explanation with examples. A third group likes to see what is going on.

The AlgoViz.org portal contains visualizations of all kinds of algorithms for the visually inclined.

 


Things Users Don’t Care About

8. February, 2013

Things users don’t care about” is something every software developer needs to know about.

Kudos go to Thomas E. Deutsch for finding and telling me about it.


Designing a Garbage Bin

17. December, 2012

Many of us have noticed that designing software is surprisingly hard but many don’t know why that is. The simple answer: Design is the art to balance contradicting goals.

Not convinced?

Let’s design a public garbage bin together.

What do we want?

  1. Big enough so it never spills
  2. Easy to clean
  3. Nice to look at
  4. Robust enough to withstand riots
  5. Soft enough to cushion the impact of car
  6. Long lifetime
  7. Cheap

It’s easy to see that “cheap” contradicts almost anything else. “Nice to look at” means an (expensive) artist has to build the form. Big garbage bins ain’t cheap. Easy to clean and robust mean high quality materials for hinges and locks. Easy to clean and long lifetime involve expensive surface materials and finishing.

It should be easy to lift for the cleaning crew but not for rioters. When a car hits it, the bin should give way. So these contradict each other as well.

Still not convinced? Look at my elevator example.


TNBT: Documentation Sucks

11. October, 2012

Documentation is the unloved step-mother of software development: Nobody likes it.

On the writing side, documentation is either considered a waste of time:

  • I could write code in that time
  • It won’t be valid anymore after the code changes tomorrow, anyway
  • There is no way to make sure you can trust documentation
  • Stringing sentences is hard work, especially when you want to make them easy to read, understand and interesting to follow.
  • It’s hard to connect code samples with documentation
  • If I describe too many details, readers will be bored. If I omit too many, they will be confused. There is no way to know which level of detail is good.

On the reading side, it’s a waste of time:

  • I need to solve a problem, I don’t have time to search in a huge dump of text
  • If the author doesn’t trust the documentation, how can I?
  • It will contain too many details that I already know and omit too many facts that I need to understand what is going on.

The core of the issue is that documentation and code are two different things. Documentation is, by nature, abstract. It’s at least one step removed from the solution.

Does it have to be that way?

I hope, with new technologies like Xtext or JetBrains’ Meta Programming System, we will eventually be able to turn documentation into code.

So instead of writing hundreds of lines of code to open a window, give it a size, make sure it remembers its size and position, etc., we could write:

Allow the user to edit a Customer object which has properties from foaf:Person and one or more addresses.

Users can search for Customer objects by any of the name fields.

Note that the links are part of the documentation and the code; the underlying code generator should follow them and examine the code/documentation on the other side.

Related Articles:


Software Development Costs: Bugfixing

21. July, 2012

(Second part of three; first part is here)

Software has bugsthere simply is no way to avoid them. If you can’t avoid them, maybe you can handle them efficiently? Yes, you can:

As you can see, the cost of fixing bugs rises as time passes. Why is that?

There are many reasons:

  • When you find a bug a couple of minutes after you created it, you probably still have all the information in your head that is necessary to understand and fix it.
  • If you just created the bug, no code depends on it. As soon as you start writing unit tests and more code, fixing becomes more expensive because you start to have dependencies.
  • People might have gotten used to the bug and developed workarounds. If you fix the bug, this will have an impact on them.
  • A bug found in production is likely to be reported by a customer. Customers can’t see inside of your software, so extra effort will have to be spent to determine what the actual problem is. Google for “how to report bugs
  • When a bug is discovered at the customer, it might trigger meetings and scapegoat hunting. Think of it this way: A 1 hour 8 person meeting costs about $1’000. And no bug was ever fixed in a meeting.
  • Some bugs escalate to the top-level management. Imagine for a moment what it would mean for you if their CEO called your CEO to complain about a problem you caused.
  • Bugs might break expensive things, harm or even kill people or start World War 3.

This also explains why unit testing is so much more efficient to QA testing for many kinds of bugs: It simply catches them before they spread their bad influence.

So fix your bugs early, OK?

Related articles:


Software Development Costs

14. July, 2012

I’ve prepared a small presentation to give an overview of software development costs.

This diagram describes the costs/gain per feature.

Complexity Curve

The most simple curve, complexity, is easy to understand: Costs go way up as you add features. Adding another feature to an already complex product is way more expensive than adding the first feature to a non-existing product.

Bugs in Final Product

The number of bugs in the final product is harder to understand. As you add features, you also add bugs. The number of bugs per kLOC is an individual constant. We always make the same mistakes and we the number of bugs we create per kLOC is pretty stable, too. The number is different for each person but every developer has their own number and that number doesn’t change much unless external circumstances change dramatically. In fact if you create statistics about bugs found per team member, you can tell how many new bugs there will be after he added N lines of code (see “They Write the Right Stuff“).

That means every product has bugs. If the project isn’t a complete disaster, then the team will have found a way to cope with these. Or to put it another way: If the number of bugs grows too fast, the project will either be canceled or drastic measures will be taken to reduce the flaws again.

This is what the curve means: In the beginning, there will be few bugs because there are only a few lines of code. Remember: number of bugs = lines of code * individual constants. Each line that you don’t write reduces the number of defects.

As time passes, the number of bugs will grow just because lines of code are written. Eventually, that number will either explode or the team will find a way to keep the number in check.

Gain per Feature a.k. ROI

The last curve is for the marketing department. It describes the usefulness of the product for a customer as features are added. A product without features (a.k.a vaporware) is not very useful for a customer. The first feature will be the most useful … or it should be: Why are you wasting your and your customer’s time with features that aren’t the most useful?

But as you add features – and trust me, customers and marketing will try to get as many as they can get – the usefulness doesn’t grow as much anymore. Each feature comes with the cost of complexity: There will be more menu items, dialogs and buttons. The manual will get bigger. The customer will need to remember more to use every feature. That starts with remembering that a feature even exists and goes on with remembering how to use it efficiently.

At the same time, you started with adding the most useful features, right? So additional features, by definition, can’t be as useful as the first ones.

And eventually, the product will contain more features than any single customer cares about. New features will be added for new customers that existing customers don’t care about or that even get in their way (when menu items move around, for example).

This is one reason why everyone feels that Google or Apple products are so easy to use: They work really, really hard to reduce the number of features in their products.

Next week: Bug fixing costs.

Related:


Jazoon 2012: Improving system development using traceability

4. July, 2012

When you develop a software, you will ask yourself these questions (quoted from here):

  • Is it still possible to accept a late change request? What would be the impact?
  • What is the overall level of completion of the system or a component?
  • Which components are ready for testing?
  • A failure occurs because the system is erroneous. What parts of the system should I check?

In his talk “Improving system development using traceability“, Ömer Gürsoy shows an approach to answer these. The idea is to trace changes end-to-end: From the idea over requirements to design, implementation, tests, bug reports and the product manual. For this to work, you’ll need to

  • Analyze
  • Document
  • Validate
  • Manage

At itemis, they developed tooling support. A plug-in for Eclipse can track changes in all kinds of sources (text documents, UML diagrams, requirement DSLs) and “keep them together”. It can answer questions like “who uses this piece of code?”

The answer will tell you where you need to look to estimate the impact of a change. That helps to avoid traps like underestimation or missing surveillance.

Today, the plug-in shows some promise but there are rough edges left. The main problem is integration with other tools. The plug-in supports extension points to add any kind of data source but that only helps if the data source is willing to share. The second problem is that it doesn’t support versioning right now. It’s on the feature list.

On the positive side, it can create dependencies from a piece of text (say a paragraph in a text file). If you edit other parts of the text file, the tool will make sure the dependency still points to the right part of the text. So you can make notes during a meeting. Afterwards, you can click on the paragraphs and link them to (new) requirements or parts of the code (like modules) that will be affected. Over time, a graph of dependencies will be created that helps you to keep track of everything that is related to some change and how it is related: Where did the request come from? Which code was changed?

Always keep in mind that tracking everything isn’t possible – it would simply too expensive today. But you can track your most important or most dangerous changes. That would give you the most bang for the buck. To do that, you must know what you must track and why.

A feature that I’d like to see is automatic discovery. Especially Java source code should be easy to analyze for dependencies.


Jazoon 2012: Agile Chartering: Energize Every Project Liftoff

4. July, 2012

In her talk “Agile Chartering: Energize Every Project Liftoff,” Diana Larsen presented approaches how you can set up your agile projects. Why is that important? When a rocket is launched into space, a lot of preparation happens to make sure the move from ground to space is smooth and successful.

Software projects often ignore this important step.

For example, it would make sense to check the commitment of team members. Commitment comes in two flavors:

  1. Yes, I want to do this
  2. … with the other members of my team

Another important question that each team member will ponder is WIIFM – What’s in it for me? Answers to these questions will have a huge impact on the success of a project.

Regulations are important but don’t forget that the human brain has a limited capacity. If you want them to follow the rules, you must restrict them to five tops.

Member Shields

Another strategy is to create “member shields” where each member writes their name on top of a shield like shape. The shield is then separated into four quadrants:

  1. Which skills to I bring into the team?
  2. What do I need to be successful in the team?
  3. What’s in it for me?
  4. Something personal. No dark secrets, just something that turns you into a person.

Write a motto below the shield.

Put those in a place where every team member can see them.

Context

Make sure that the team members know where the team fits into the organization. Post a 10’000 feet view of the company somewhere.

Risks

Agile development is all about risk management: Notice them, rate them, discuss them, act on them.

Good places to look for risks: Team boundaries and interactions: Who depends on the team’s work? On whom does the team depend? Does the team have everything it needs?

What does the team know about the future? What do we not know? What are opportunities and threats?

Remember the PAC triangle: Purpose – Alignment – Context. Every move of one corner influences the other two as well.

Also a lot of risks have their roots in VUCA:  volatilityuncertaintycomplexity and ambiguity.

Related:


Jazoon 2012: Architecting non-trivial browser applications

28. June, 2012

Marc Bächinger gave a presentation how to develop HTML5 browser applications.

The big advantage of HTML5+JavaScript is that it gives users a better experience and usability. One of the first steps should be to decide which framework(s) you want to use. You can use one of the big, monolithic, one-size-fits-all frameworks that do everything or select best-of-breed frameworks for specific aspects (browser facade, MVC framework, helper libraries and components).

You should use REST on the server side because that makes the server and the components of your application easier to reuse.

The main drawback is that you have (often much) more complexity on the client. This can be controlled by strict application of the MVC pattern.

Browser facades

Every browser has its quirks and most of the time, you just don’t want to know. Browser facades try hard to make all browsers similar. Examples are jQuery and zepto.js

MVC frameworks

Backbone.js, Spine.js, Knockout.js, ember.js, JavaScriptMVC, Top 10 JavaScript MVC frameworks

Helper libraries and frameworks

gMap, OSM, Raphaël, jQuery UI, Twitter bootstrap.js, mustache, jade

Important

Since the whole application now runs in the client, security is even more important since attackers can do anything that you don’t expect.


Follow

Get every new post delivered to your Inbox.

Join 333 other followers