Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,546
|
Comments: 51,163
Privacy Policy · Terms
filter by tags archive
time to read 2 min | 208 words

I am a firm believer in laziness. But as a contra weight to that, I also believe in responsibility.

I made a mistake with the back office for NH Prof. Instead of setting the trail date for 30 days, I set it for one month. It wouldn't matter that much, except that this is February now, and the month is only 28 days.

It was pointed out to me, and I realized that I had, inadvertently, misled my users. It is acceptable to make mistakes that counts against you, that is just tough luck. It is not acceptable to make mistakes that counts against your users.

Going back to the title of the post, obviously I needed some motivation to work on NH Prof backend. To be fair, I consider the NH Prof backend to be really annoying side tracking, but that is not a good excuse for this.

Something needed to be done!

So, anyone who got a shorten trial period is automatically extended to 35 days (they would need to download the license again) and everyone who is coming to the site is going to get 31 - 33 days of trial.

Hopefully this will motivate me to pay more attention during my midnight coding.

time to read 3 min | 574 words

The absolutely hardest thing in most projects is to (and I am going to be blunt), to get the customer to shut up and let the team start working. I have been in several projects where the actual move from blah blah talking to actual doing was a painful and drawn out process.

In one particular example, I was brought on as a team lead for a team that had 4 months to produce a system. I was stunned to discover that the last two years were spent in meetings on top of meetings on top of meetings. At some point I flat out abandoned the spec, forced got management approval to talk directly with the users and started supplying them what they wanted. I still consider this to be a horrible project, but at least we shipped.

I found several approach that can facilitate the move from talking to doing. The first one, and the one that I prefer, is to actually start building the software. Now, I don't refer to building the actual production software, but to building a spike of how things are supposed to work. Show it in the next meeting, and I can almost guarantee that the discussion is going to shift radically.

When you put something in front of people, especially since in spike mode you can get things done really fact (no code quality, no error handling, pure nasty coding). In several past projects, I have used this approach to leap over the "let us just get started" hurdle.

The main issue is that the business would like to really understand what they want to do, before asking the developers to do so. But since many things are fixed already, that is, the general concepts are already known, and the devil is in the details, we can start painting the outline of the system in broad strokes and fine tune it later.

The idea is to push the business into that mode. And spikes get us there quickly.

Another method that I have started to use lately (which is even easier than spikes) is the use of UI mock up. Using a tool like Balsamiq Mockups, this is ridiculously easy. It also serve as a great spur to actually starting to do things. Instead of getting mired in details, I can get a pretty good picture of a vertical slice of the application, and go away and actually implement that.

Here is a mock up for the landing page for the NHibernate Profiler web site:

LandingPage

You can see the real thing here. As you can see, it isn't the same at all, but I think that we can all agree that there are marked similarities between them.

This mock up took about 3 minutes to build, and we did that while on the phone and with screen sharing. But it meant that we talked about something concrete.

When you are starting to talk in concrete terms, you have already much closer to getting starting doing something real.

Those are just a few example of initiating actions, actions that can get you to move from the talk talk talk phase into the get things done phase. It is important to make this move as soon as possible, for several reasons. Not least of them is that we value working software over comprehensive documentation and lengthy discourse.

FUTURE POSTS

  1. Partial writes, IO_Uring and safety - one day from now
  2. Configuration values & Escape hatches - 4 days from now
  3. What happens when a sparse file allocation fails? - 6 days from now
  4. NTFS has an emergency stash of disk space - 8 days from now
  5. Challenge: Giving file system developer ulcer - 11 days from now

And 4 more posts are pending...

There are posts all the way to Feb 17, 2025

RECENT SERIES

  1. Challenge (77):
    20 Jan 2025 - What does this code do?
  2. Answer (13):
    22 Jan 2025 - What does this code do?
  3. Production post-mortem (2):
    17 Jan 2025 - Inspecting ourselves to death
  4. Performance discovery (2):
    10 Jan 2025 - IOPS vs. IOPS
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}