Category Archives: Business of Software

You’ll find posts in this category that are about the business of creating software and running a software business. Not strictly related with information security, not strictly related with one of our tools.

Dradis Framework Founder’s Letter – 2017

Good Software Takes Ten Years. I didn’t know that when we started back in 2007, but I’ve come to terms with that rule since then. A lot can change in 9 years. You can go from the first commit of an internal project released as open-source to a small, independent, self-funded software team that is making a difference for 300+ teams in 34 countries around the world.

Did I have a clue about where we’d get in 9 years when I pushed that first commit? Most definitely not. Was I confident that we’d be working with 1,000s of InfoSec experts every day when I quit my security consulting job over 2 years ago to concentrate my efforts on Dradis Pro full time? Not even close. Do we have a clue about where we’re heading over the next 2 years? We have clues but most likely, we really don’t know. But that’s fine, we’re not alone in this journey. We’re bringing our entire community along with us. And most importantly, we have the freedom to choose where we’re heading.

We don’t have investors so we can keep our users front and center. Were trying to grow as slowly as possible. By focusing on the fundamentals, we’ve managed to get this far. And, we’re sticking to the same approach going forwards: do the work, keep our users happy, and care about their long term success.

A brief history of our project

Just to put things into perspective, here is what working on the same piece of software every single day for 9 years did:

  • Dec 2007: Start working on an internal tool for pentest collaboration.
  • Jan 2008: Release Dradis Framework as open-source.
  • …3,000 code commits.
  • Jul 2011: Launch a side-business offering additional functionality and official support (Dradis Professional announcement).
  • …work with 140 teams, 17 new releases, 2,967 commits.
  • Feb 2014: Make the side-business our main business.
  • …7 new releases, 782 commits.
  • Mar 2015: Welcome Rachael, our second full-time member of the team
  • …13 new releases, 2,503 commits…

The last 12 months

With the growth in the Dradis Pro side of things, we have been able to reinvest a lot of man-hours in Dradis Community Edition. It’s our way to give back to the community that helped us along the way. The code was refreshed and updated. Many of the enhancements that were created for the Pro edition were backported to CE. Plus, the documentation was rewritten, step-by-step guides were created, and screencasts were recorded. We also created and released OWASP, PTES, HIPAA and OSCP compliance packages with testing checklists, report templates and more.

Dradis Community edition GitHub repo commits in 2016

The activity in the Dradis CE repo shows how a lot of this effort was concentrated earlier in the year to sync the CE and Pro code bases (kudos to the GitLab team for the inspiration).

Our community is growing stronger than ever. We’re averaging 400 git clones each week. Plus, we have a thriving Slack channel and dozens of new threads in our community forums.

Dradis community edition is being downloaded an average of 400 times per weekWhat we are going to be focusing on over the next 12 months

Over the last 12 months, we’ve pushed 11 new releases of Dradis Pro. From performance and interface to functionality and stability, we’ve noticeably improved every single aspect of the app. The product today is in a completely different category from where it was 12 months ago. And still,  there is so much room to grow, refine, and improve!

2017 is exciting for us in many ways. We’re now working with over 300+ teams. This is a challenge, but we wouldn’t have it any other way. Plus, this the first time that we have a small team of very talented people working full time on taking care of product development and user experience.

I’m sure that the speed at which we’ll be making progress is going to feel break-neck. I can’t wait to see the things that we’re going to be able to build with you and for you and the rest our community.

To our best year ever,

Daniel

Praise for Dradis Pro from a Customer

We recently talked to one of our Dradis Pro users. You may be familiar with him: security consultant, researcher, and software developer Robin Wood. He goes by @digininja on Twitter, and has a pretty large following on there. His site is at digi.ninja.

We asked Robin some questions about how he uses Dradis Pro, what he finds most useful, and his tips for new users to the software. Here are the edited results of our talk.

Can you walk us through a typical workflow for you and how Dradis Pro plays a role in that?

RW: Projects usually start when a client confirms the job and sends over an initial brief with things like IP addresses, URLs, and other information. At that point, I create a new project in Dradis. I put all the info in to get it started–basically just an initial capture. This might be a week or two weeks before the job itself.

Once the project has begun, it’s fairly typical. I collect all the data into Dradis.just like most people would collect data, no matter where they’re collecting it. I don’t tend to use any bulk import features because a lot of the work I do is web apps, so the findings are more bespoke.

As I’m working, I put findings directly into Dradis Pro and I pulli prewritten findings from MediaWiki, which I use as a findings repository because Dradis communicates easily with MediaWiki. So even for the more sort of rarer or obscure issues, I will still have some kind of template I can start with, instead of redoing it.

Obviously not every client is the same. So I don’t want to give out the same templates or findings to everyone. But I also don’t want to be rewriting the same thing over again. So I just go in, slightly manipulate it around to be bespoke for that customer, and then that goes into the report.

So during the test, I’m going through, doing all the testing, building up all the findings. I always try to take more notes than are necessary, and note everything I find, particularly when it’s an onsite test because I know I can’t go back and check things. In Dradis, I take screenshots, I write up notes on everything, I record everything down to individual IP addresses and one-liners that may be useful. They may not be useful, but then I’ve got them just in case.

At the end of the test, the report creation depends on who I’m working for. Some companies or agencies like to use their own reporting template. If there’s a Word doc template, for example, I’ll do a bit of copying and pasting from Dradis into the document.

It’s much easier when I’m doing work for my own clients, because Dradis has automated reporting features. I just hit a button to generate the reports in whatever format I want, and out pops the report at my end, mostly done for me. Then it’s just a case of a little tweaking and putting a few last bits of customization on it.

How has Dradis proven useful for you?

RW: As soon as you start using a structured format for projects, you realize it’s so much easier to go through and see what everything is.

It’s like: ‘Why haven’t I been doing this the whole time?’ The problem is that you think, ‘My process works as it is, so I don’t have the time to put more effort into it. I’ll just use what I have.’ Then you’ll improve something and find a better way of doing it, and think, ‘Why didn’t I do this six months ago? Why didn’t I do this a year ago?’

What would you say is your favorite feature in Dradis?

RW: Probably having the issue library. It makes a big difference. In every test you do, you think, ‘I know I’ve written that one up before.’ And before, I’d have to dig through all the reports, going, ‘How did I write that up before? I know I did a good description of this at some point.’ With the issue library, I write a good description and I put it in the library and it’s always there for me. I don’t have to reinvent the wheel.

What sequence would you recommend for new Dradis users?

RW: I would go with the issue library first, because on most projects you’ll be repeating many issues. So start getting the library built up fairly quickly. From there, you’d go to the reporting side of it, and try to get yourself a report template made up. You’ll want to start small and slowly build into it.

How does Dradis Pro help your clients?

RW: They get more detailed and more time-tested descriptions. This makes it easier for them to understand what’s going on and makes it easier for them to remediate issues.

It also helps with on-site tests as I can sit down with the client and walk through each issue with them. There’s a nice onscreen display with a full list of issues. I can click on them, show them the descriptions, and there’s a graph that shows how many high, medium, and low risks. You can’t do that with a basic text file.

Also, it’s easy to find past project data. I had a client get in touch yesterday. Their test took place six months ago and they had questions about it. I can easily pull the archive, decrypt it, and I have all the data for them. It’s there, ready to go.

Thanks a lot to Robin for taking the time to talk to us and sharing his experiences. We very much appreciate it.

Software quality: creating a software product you can live with

When creating a software business there are a lot of things to consider and many decisions to be made. One of the most important ones, especially if you are by yourself, is: how high are you going to put the software quality bar?

Giving the day-to-day pressures to build up the business (do you have a business or do you just think you do?), the multiple feature requests by your users, the support requests you have to tend to, the pile of ideas you’ve got in the roadmap and the limited time in each day, it is clear that some compromises must be made. You’ve got to strike a balance between having enough features that your tool is compelling and making sure that what you have actually works (otherwise people that you worked so hard to convince of using your tool will be frustrated and abandon it).

In the early stages

Remember the classic essay by Joel Spolsky Good Software Takes Ten Years. Get Used To it, yes it takes time to create a great product, but you need to make sure that your company is going to survive long enough to get there and you need to make sure you’re still enjoying what you are doing years down the line 🙂

During the early stages, not every feature we’ve pushed in a release of Dradis Pro was as polished as I’d have liked, but at the time we thought it was the right choice: push the feature out and let our users start benefiting from it. However we’re not in the early stages any more. We’ve been two years in business, with a growing client base and heathy amount of new sign ups every month. Now it’s the time to take two steps back and look at the big picture, to prepare ourselves for the next ten years.

One of the most important things to learn and keep in mind, even more important to those of us coming from an engineering background is that your users don’t care about your product. They don’t want to use your product for the shake of using a product. They want the results they’ll get from using your product, that’s where the focus should be. Let me repeat that again as it is quite important:

Your users don’t want to use your product,
    they want the results they’ll get from using your product.

This means you have to identify what this end results are and focus your efforts in making it ever easier for your users to get there. This often means spending time refining areas of your tool instead of adding new features.

Balancing scope and software quality

In the era of the Lean Startup, the above ties nicely with the concept of minimum viable product: in order to become sustainable, you need to identify several key pieces of functionality that when put together are going to allow your users to get the end results they are looking for. [Note that I’m talking about being sustainable (i.e. generating enough revenue to reinvest in the product to improve it), not just in order to sell or in order to find users for your product. You can sell almost any piece of broken software for a low enough price. But that’s a different discussion for a different time.]

Throwing together those pieces and making sure that they can be made to work together as a coherent application is the very first stage in the lifecycle of the product. This means you’re solving a real problem, for real people, that will pay real money to get their problem solved. However, in the path to this first summit in your journey, you may have to release half-baked solutions or quirky code you are not proud of. You may even do this without being conscious about it (at the end of the day, you’re fighting an uphill battle, and getting results is the only think that counts on a daily basis).

There is a tipping point where you realize that the strategy of knocking together functionality and releasing it is not going to work in the long run. You are accruing too much technical debt. If you are hoping to be developing and maintaining your tool for years to come, you better make sure that you are creating something that you will want to maintain, something that you are proud of.

I saw the light while reading the Designing Web Applications book by Nathan Barry a few months ago. In particular a section discussing the ideas of Ryan Singer, Software designer at 37signals, on product quality:

I like to visualize software. Here’s an intuition that works for me. Feature complexity is like surface area and quality of execution is like height.

A hand-drawn representation of a software product like a surface, with different areas dotted in it and the height of the shape representing the qulity.

I want a base level of quality execution across all features. Whenever I commit to building or expanding a feature, I’m committing to a baseline of effort on the user experience. That way feature complexity — scope — is always the cost multiplier, not user experience. There aren’t debates about experience or how far to take it. The user experience simply has to be up to base standard in order to ship, no matter how trimmed down the feature is.

(Ryan has an article on his blog about the subject: What happens to user experience in a minimum viable product?)

Even though conceptually we’d all agree that it’s desirable to build good quality products, Ryan’s surface/heigh metaphor makes it really easy to understand the end goal we’re striving for and the reasoning behind it. It is a great tool that you can keep on the back of your head and use to drive your development efforts on a daily basis.

Keep your focus

It’s more important to ensure a consistent height across all areas of the product than it is to expand the surface. In fact, it is a trade off, there is no expanding the surface if the heigh isn’t going to be kept consistent.

This helps in narrowing the focus of what you’re trying to build, less surface, more height, build something great. This isn’t new, and there are many ways to phrase this feeling, but I always remember Bill Crosby’s:

I don’t know the key to success, but the key to failure is trying to please everybody.

You product can’t be all things to all people. This is why you’ve seen a multitude of minimalist text editors thrive by focussing on what is important and nothing else (iA Writer, Writeroom, Byword…). Have the basics taken care of before thinking about adding new stuff. As Julie Zhuo, Director of Product Design at Facebook puts it, there is a tax associated with every new feature you introduce that you better understand.

Making this shift, this change of focus towards quality, clarity and purpose has benefits all around. It makes you proud of the work you do and it helps to ensure that you don’t have too many features that you can’t pay attention to.

This is where we are going for the next few releases of Dradis Pro: don’t expect a lot of growth in the surface, we’ll focus on pushing and levelling our height, always keeping an eye on the results our users want to realize.

I’d like to wrap this post with another quote about quality and building a software product, this time by Jason Fried also of 37 signals:

It better be good, because people are depending on it to be good

How to choose a software vendor

So, you’ve decided you need a software vendor to build an application for you. It might be an idea you have for a great new product, or a tool that needs to integrate with an existing system, or an application to automate a manual process in your organisation.

I assume you know a little about software but you do not have much experience in how applications are built and how software development teams operate; you would like to know how to pick a software team that will build a quality product, that will understand what you need and contribute to the success of your business.

To give you some background, I am a software engineer, have led software teams, outsourced projects to remote software teams and delivered work for remote clients. I would like to share a few ideas to help you judge if a software team is worth their weight in gold.

How well do they communicate?

You will be spending a fair bit of time with the team you pick. You’ll explain your idea to them, they’ll explain their approach to the project, It’s important that you understand each other, that you click, that you are on the same wavelength. When you explain your idea to them they should understand it and be able to contribute constructively to it. When they explain their implementation to you it should be in such a way that you can understand. Successful communication is critical to the success of your project – pick a team that you can communicate well with.

Do they understand your business domain?

It is incredibly valuable if the team that you engage with understands your business domain or the industry that you are in. Have they worked with clients in your industry before? Do they specialise in a specific domain and does it overlap with yours?

A software team that understands the context in which an application will be used, will spend less time trying to understand the problem space and more time focussing on the solution. You might have a very clear documented vision of your application but inevitably decisions need to be made during development by the development team. A software development team makes better decisions when they understand the business domain.

Do you like their existing work?

Past behaviour predicts future behaviour. You can tell a lot from a team based on work that they have delivered in the past. Most teams would be happy to share a portfolio with you of applications that they have built before.

Do they design clear and easy to understand user interfaces? Is it intuitive to use their applications? Do you get a sense that they have thought through every scenario in which the application might be used? Do they take pride in their work?

Are they willing to involve you in the process?

A good software team values continuous contribution from their client. Be wary of a team that vanishes for 3 months with your requirements with the promise that they’ll deliver the perfect product when they return.

Before any line of code is written they should involve you in their planning process or at least give you clear visibility on their planning. When development starts they should be able to show you their progress on a weekly basis and invite your feedback.

A good software team understands that requirements may change during a project and they embrace change, knowing that certain things become clearer only during development.

Do they have good software development practices?

Even if you are not very familiar with software development you can still make a judgement of a team’s engineering practices by asking a few simple questions.

Do they test their software? Good software development teams have diligent process through which they test their software. You can reasonably expect testing to be partially automated and partially manual. I would be careful if they do not do a fair bit of each. Most teams would be happy to discuss this.

Do they break their projects down into small testable chunks of work? Similar to manufacturing, it is best to break a software project into small well-defined pieces of work that can be tested from a user’s perspective. Successful teams have a well-defined process by which they define, implement and test pieces of work and measure their overall progress (protip: why can’t developers estimate time?).

Do they frequently deploy their code to a production like environment? It is important that deployment to production is part of the development process early on in the project. This eliminates surprises at the end. It is also important that this process is automated.

Do they have a process in place to deal with bugs? Teams should have a process in place through which they track, prioritise and fix bugs.

Are they familiar with software security? Good software teams consider security from early on in the development project and have checkpoints in place during the project to review security of the application.

How do they stay on top of the latest technologies? Software development is a fast changing industry. Good software teams encourage and support their developers to read, attended conferences, have side projects and experiment with new techniques.

Do they contribute to the software community? All software teams rely heavily on the wealth of knowledge that is provided by the software community. Healthy software teams give back to the community through publishing their knowledge, contributing to open source projects, speaking at conferences, etc.

What is their public reputation?

A good software team has happy clients (client testimonials), they engage in conversation in the public domain (twitter, mailing lists), they are regarded as specialists in their own domain (blogging, speaking at conferences), etc.

Wrapping it up

The above pointers are aimed to help you to judge a vendor’s maturity in few fundamental aspects of software development without having to know the industry jargon. There is more to software development that can be covered in a single blog post but hopefully the above will enable you to have a confident discussion when engaging with a software team for the first time.

About Sibert Lubbe

Siebert is a software engineer, enthusiastic about all things software related – the code, the people, the business, the processes and emerging technologies.

He is based in Melbourne, Australia currently working at realestate.com.au. Find him on Twitter as @siebertlubbe or at siebertlubbe.com.