Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

Are spec documents still necessary for software development?

I recently acquired a major position in a telehealth software company and assumed CEO role. The company offers teleophthalmology and virtual care solutions for the eye care industry. I am a marketing and sales guy but I have 25+ years in technology and am pretty technical in a general technology sense. The co-founder of the company has stayed on as a partner in the venture and is responsible for product development and operations. He's not a software engineer so much as a general IT/tech guy but he's the one who has overseen development of the company's products since day one and continues to do so. He has also gained quite a bit of eye care industry knowledge.

We have identified the need to develop an important new product that will offer us tremendous competitive advantage and a growth opportunity. I am told that the underlying R&D work has been done and that we are ready to start building the product. We have just hired 2 new developers (junior level) who will focus on this new product under the supervision of my partner and our lead software developer (more experienced individual but fairly new hire and I'm not sure of his capabilities yet). I asked my partner if he has prepared a spec document and he said it's not really necessary. I was pretty surprised to hear this. He says it's all in his head and he knows what needs to be done. o me, this seems a bit cavalier. I know for a fact that this product is not that straight forward to build and there are many complex aspects well need to figure out. I'm a bit old school and have always thought that spec docs built on solid use cases combined with wireframes and UI mockups was the way you designed software. My partner says that this is not the way it's done these days. He says you use short iterations cycles and adjust course rather than follow a master spec doc.

Is he right? Should I just take his word for it? The goal is to have an MVP to demo at a major trade show at end of October. Do I just wait and see what happens? Or, should I press him for a dev plan of some sort? What should I insist he provide me with so I can be assured than the funds I invested are being put to proper use?

69 Replies

Larry Shiller
6
0
Larry Shiller Entrepreneur • Advisor
Grit: The new dimension in college admissions
Whatever software development methodology you use, without documentation you won't have a good way to know if what you built is what you want - whether it's a one-week sprint or a 3-month development cycle. It is possible that your partner is an "information hoarder": Someone who values the knowledge they have that no one else does. If so, having sensitive antennae along with intolerance for information hoarding behavior will result in better outcomes. If your partner insists on not documenting, shorten the sprint cycle to a few days to minimize your documentation debt.
Anthony Miller
7
0
Anthony Miller Advisor
President & CEO at millermedia7
Hi Richard!

Sounds like he is referring to agile software methodology, which we run on as well. We write out all of our stories and then assign them to our dev team, each story has its own weight. Based on the amount and weight of these stories we do software releases every 2 weeks. But to have it all in his head and to not hold sprint planning sessions every week with the team seems too loose. You need to have an overall product vision and be able to understand which features you'll need to have ready for this big date in October.

Sounds like this person may also be a little inexperienced. I'd be worried that you won't hit deadline for this MVP. Best thing you can do is tighten things up. Understand what can be done in the amount of time you have available to you. Make sure you have your roles and process down before starting or you may see them not able to hit these small interation deadlines.

Hope this helps.
Kevin Carney
1
0
Kevin Carney Entrepreneur
Content Marketing Training and Consulting
Larry is right. You need a spec. At the very least it makes it possible for the ideas to be reviewed and discussed. It doesn't matter that the 2 new developers are junior. They need the big picture in order to fill in the details well, and the are always various ways to do the details.
Jesse Merl
2
0
Jesse Merl Entrepreneur • Advisor
President Gatsby TV
Depending on budget, my suggestion is to hire a qualified CTO if the software effort is going to be a critical component to your business moving forward. You can use contract development as long as you have someone in house owning the build, leading, and managing the contractors. With contractors you will definitely want to build out requirements and spec docs but your CTO will handle that. Don't try to be something you aren't and learn as you go. I learned that one the expensive way.
Jack Bicer
1
1
Jack Bicer Entrepreneur
Founder & CEO at Sekur Me ("Father of Uninstall")
If it is going to take more than a week, developing software without a spec is like playing a Russian roulette. Except every chamber in your pistol has a bullet.


Robert Lasky
3
0
Robert Lasky Advisor
Digital Executive, Consultant and Cross-Industry Channel Expert
The short answer is yes, you still need a spec so that your partner and you agree on what's being built for the MVP, and so your partner can develop the sprints he's referring to in order to get there (sprints are the short iterations he's referring to). Without that, you're both introducing a lot of unnecessary risk.

Typically, sprints are one or more stories developed in a 1-2 week cycle. Semantics aside, stories provide the same value as requirements. You probably have to agree from a business standpoint, your partner from a technical standpoint, and the developer from an implementation standpoint. At the end of a sprint, it's black-and-white... Was the requirement built? Does it work? Etc.

There are a couple of major problems with the head of development keeping specs in his head, aside from it being a sloppy way to handle development:

1. If he steps off the wrong curb, you're done (sorry for using such a bleak example).

2. It leaves too much room for subjectivity (e.g. he explains casually to a developer, they build and test, he says what was built isn't what he meant / they discussed, you've all wasted and lost time.

There are many problems that fall out of these (politics, culture, etc.) but I don't think they need to be elaborated here.

What you ultimately agree upon may not need to be exhaustive like in waterfall or iterative development if he's trying to be more agile, but agile is far from a free-for-all.

Good luck!
Anders Sandell
1
0
Anders Sandell Entrepreneur
CEO & FOUNDER at TANK & BEAR INC
I would echo Anthony's advice. One I would ask him to lay out an over all schedule for the sprints. And I would also press him to have a UX designer develop wire frames along with user stories so that the entire team has a united vision for the product. For key interactions and user flows you can have a designer create clickable prototypes in a tools such as Invision or Adobe Experience design. I don't like the sound of the design being just in a person's head. Software development and design is a team driven endeavor and you as the key stake holder should have a good understanding of what's being built.
Robb Vaules
0
0
Robb Vaules Entrepreneur
Western Region Marketing Director
Coming from Teleradiology, I worry about your service up-time. We were online 24/7 with STAT reads, so we really didn't have a window for software changes. We were always live, and always in a situation where we were delivering emergent patient care.

I believe, in healthcare, you will need to have a software spec document. Not only for a solid development plan, but also to plan for those times when you might need to be offline as well as what the changes are going to be so as to communicate them to clients. Will there be a need for regulatory (FDA) approval? It's nice if you are incrementally changing the product. Clients get grumpy if there isn't communication, and to me, that is part of a software development doc. It's a marketing, sales and financial doc, etc.

You might not have the emergent situation of telerad, and that's fine, but I have seen the results of not having a developed plan laid out and it's negatively affecting patient care.
Mychal Werner
0
0
Mychal Werner Advisor
Marketing at Exciting new Venture
Are you intending to be purely a consumer product which has to satisfy only the consumer, or are you looking for this product to go into a regulated, i.e. healthcare space? If a physician or optometrist is using it, you should check what the regulatory status is you will be seeking.

I have worked on many SW products that are FDA regulated and anything you bring for diagnostics absolutely has to be documented. My assumption is that you fall under this category? Do you have a quality system set up? This is the system which specifies the exact documents required, and most quality systems for an FDA submission would require the following development documents
Marketing requirements -->Product requirements --> (SW) design specification--> (SW) design requirement --> test protocol --> test report
Basically at the end, to satisfy the FDA you need test reports that trace back up the chain, that the design requirements were met, the specifications were met, the product requirements were met and the market requirements were met.

Happy to elaborate if needed.

This was always a conversation / argument between the eng dev team and our management team when developing. Most of the time, the decision was that we HAD to have all of these documents, so that we could prove we had designed the system to solve the right problem, and that it did indeed work to solve that problem. Using this discipline in development can solve a lot of problems later.
Good luck.
Ben Hibben
0
0
Ben Hibben Entrepreneur
Cofounder at MrBlinkyBling.com
Yup; I've been writing code since the 90s and I promise a spec is a very important tool to help avoid Scope Creep and measure progress (regardless of methodology). I won't do a project without a detailed spec that informs the UX and then the UI elements so the users end up not just with a functioning piece of software but also something that is easy to use and makes sense when users are using it to solve their problems.

Also: what happens when he gets hit by a bus and someone new needs to step in and lead this charge??
Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?