Winners at Disrupt Law!! Spark-athon (InternetWeekNY)

Posted by K Krasnow Waterman on Sat, May 25, 2013 @ 11:05 AM

Tags: software development, legaltech, entrepreneur

In the midst of torrential downpour and flash floods, more than fifty intrepid developers and lawyers turned out for Internet Week NY's Disrupt Law!! Spark-athon.  Soggy and enthusiastic, they networked for new legaltech in a great space provided by WeWork Labs in Soho. 

K & Sparkathon Winnersdescribe the image

Dreamhost prizes were won by Hector and Paul (below left) for their ideas and enthusiasm.  We're not going to spill the beans about those here - LawTechIntersect has promised to host a VC/Angel pitch night if four new ventures were sparked!  The crowd was pin-drop quiet for great talks by Tom Chernaik (CEO, CMP.LY), Steven Cherry (Journalist, @TechWisePodcast), and Matt Hall (Founder, Docracy).  Tom announced CMP.LY's exciting new Command Post product!  Steven taught us we better get working on our kaggle score.  And, we saw a real live Docracy-crush by a very happy user.   

describe the imagedescribe the image

Thanks are due to volunteers Jennifer, Jared, Taier, Matthew, and Lesley, and for the help from Jonathan Askin.  Thanks, too, for support from the members of New York Tech Meetup, New York Legal Hackers, and nyhackers!

Article has 0 Comments. Click here to read/write comments

Software Development Cost Overruns & the Titanic

Posted by K Krasnow Waterman on Sun, Dec 16, 2007 @ 22:12 PM

Tags: technology for business managers, technology management, software development, software development cost

What do software development and the Titanic have in common? They both hit icebergs! It sounds like a bad joke, but there's an important kernel of truth here.

The software development process, unfortunately, has a predictable pattern. You, as the business leader, meet with software developers and reach agreement on "system requirements." The programmers toil and arrive with the new software and both sides are immediately unhappy. Developers think you change your mind. You think developers don't listen.

What really happens is what I call "the iceberg" phenomenon. Both sides believe they have a meeting of the minds and don't realize that their agreement rests upon a tremendous number of assumptions. You and the developers each understand the words, phrases, and concepts of any requirements document in the context of your own experience and environment. Like an iceberg, the words that are used are the 10% that both sides can see; under the surface lies the 90% that defines their differences and creates the many risks that increase time and cost.

For example, programmers don't know if a particular design will have legal implications or will cause problems for someone in the supply chain. Business professionals are facing time pressures that keep them from providing the tiny details of date formats (12/31/2007 vs 31/12/2007) or country codes which may be critical to the business. On the other hand, I once discovered business professionals phrasing a requirement in a way that was about to cause ten weeks of programming, when the right question reduced the issue to a ten minute text change. That's an iceberg!

So, what's the "sonar" for this problem? Here are four alternatives:

1) Find a translator. If you can, find someone who has worked in both worlds and can serve as the "translator" for both sides.

2) Make everyone a translator. Assign someone to create a "lexicon" - a glossary of terms that are unknown to one side or the other. To avoid definitions filled with new inscrutable terms, ask contributors to check with a twelve year-old to see if the explanation is intelligible.

3) Create ambassadors. When possible,insist that a designer or programmer spend time at the side of the person(s) who will use the system. It's amazing how much the developers can learn through watching the workflow, overhearing an occasional conversation, or a chat at the coffee machine. If they are inalterably offsite, consider collaboration tools, giving people the ability to see and hear as much of the user's current business process as possible.

4) Require an "open" development environment. Remember that the vendor's work is not a surprise Christmas present. Consider the unorthodox approach of keeping the vendor's progress accessible at all times. Rather than waiting for benchmarks, assign someone to regularly view the developer's work. Developers using best practices will have wire diagrams, screen mock-ups, and functioning modules that will allow for course correction long before the code is finished.

I know that everyone is facing business pressure to be somewhere else, doing something else -- usually something that seems more directly relevant to the bottom line. But, I guarantee that time spent with developers while they work will save vastly greater amounts of time and money later.



Article has 0 Comments. Click here to read/write comments