Archive for the 'Education' Category

The Pragmatic and Practical Design Template (Discussion)

Discussion

(Just Jump to Design Template)

We are all designers at heart. When we are little we construct models with play-doh and virtual worlds with crayons. But somewhere along the way, particularly in engineering domains, we lose this view of design as a simple model of reality and instead insist that a model must be as close to reality a possible. A design is a plan -or probably more correctly “a guess”- for something you want to create. Its only purpose is to get you from the “thinking about” to the “building” stage as quickly-and reasonably-as possible. For some domains, space travel and nuclear power for instance, you need this stage to be much more precise and deliberate, but fortunately few domains require this level of fidelity/reliability. Particularly in quick-to-release and prototype software, you need the design stage to be quick yet useful and add value. You don’t want to invest a bunch of effort in a model that isn’t the final thing you are going to use, but you do want to show that you have at least thought about that thing in advance.

I’ve been thinking about Software Design lately because I need people to do (and want to do) this activity, i.e. show that they have thought about and planned things beforehand, but even after many years I’m still not sure the best means to achieve this end. I’ve read lots and lots of design documents and rarely are they instructive or useful. These things can cost a lot of money and time to produce, but rarely do they return tangible benefits – mainly because most of the software designs/plans/guesses are out of date as soon as they are written. In fact, the only designs I even remember actually reading and using are the ones that defined some type of data interface contract, and that was because this contract didn’t change (or change much).

So maybe it is time for a different approach to the standard “Design Document.” Perhaps a better approach is just a couple back-of-the-napkin, top-level diagrams + a simple FAQ that answers some of the most important questions. The top-level diagrams show that you have thought about this at some level of abstraction and that you can show the major parts. The FAQ is used to make a convincing argument for building this thing and the approach used. The right set of questions might even be applicable to a wide range of projects, from remodeling your bathroom, or having a medical procedure, to multi-million dollar software projects.  This FAQ answers the basic and paramount questions of “Would you do this yourself? And spend your own money on this?”

For any design or other explanatory write-up, the FAQ questions you should be able to answer (and answer clearly and concisely) if what you are planning to work on is useful and worthwhile are:

(Jump to Design Template)

 

Design Tools

Design Tools (CC2 – Paul Stein – Original Image: https://flic.kr/p/qhsUF)

Advertisements

The Pragmatic and Practical Design Template

The Pragmatic and Practical Design Template

For discussion/background see this post.

Note: any answer here should be less than 3 sentences, the shorter/clearer/more concise the better – 1 sentence even being optimal. If it requires more, then you probably aren’t using understandable & clear user-focused language. Avoid references to specific technology as much as possible –e.g. instead saying “XML” just say “a file” or “a format” – terms everyone is going to understand. Not all of these questions below are applicable to every case, so don’t try to answer if they don’t fit/apply.

1.           What problem are you solving?

a.            Was something not possible before that should be possible now? Or that you couldn’t do another way? What do you hope to gain?

b.            What is it for? Who benefits? What is the motivation behind it?

2.            What is your high-level plan for solving the problem?

a.            What is your plan?

b.            Commitment: When (what specific date) are you committing to do this by?

c.             Show your high level diagram (typical Level of Detail expected: whiteboard/back-of-envelope/napkin)

3.            Why are you doing things this way?

a.            What are the primary drivers?

4.            Is what you are creating adding value?

a.            Can someone get more out of this approach/thing than they could before?

5.            Will this change behavior?

a.            Is what you are working on really going to change anything? Will someone *want* to use this because it makes their life simpler/easier/more productive?

6.            Is there any alternative or easier way?

a.            What are the alternatives? Are they easier? Cheaper? Quicker?

b.            Does something similar already exist?

c.             How are you able to get more value out of this design than you could with something simpler/easier/quicker?

d.            If this is something hard-to-understand or explain above: What is driving the complexity of this design and is this really the simplest way? Are you using customer-focused language? Have some steps been over-complicated?

7.            Is this actually useful?

a.            Are you making something useful or just making something?

8.            Is what you are doing really worth it?
Remember: don’t go throwing good time after bad work and you can’t get back the money/effort you already expended, so don’t necessarily consider the resources already invested (“sunk costs”).

a.            Is the time, energy, effort, cost, etc. worth what you hope to gain?

b.            What do you hope to gain?

9.            Are there any other dependencies or risks to consider?

a.            Does what you are doing depend on anyone/anything else at all? What are these dependencies / risks? Can they be minimized (by isolating some part of the system)?

10.          Is what you are doing usable in different environments? Is so, what are these things that won’t change in this new environment?

a.            Note: This is the lowest priority for getting work done quickly, but remember to focus on what won’t change as this project matures/ages: good workflow, data model design, portable data – these don’t change & can be useful and used anywhere.

b.            For example, if you do something in .NET, is the design still solid/applicable and is the back-end data still useful if I have to implement this in Python or JavaScript? Code itself is actually fairly useless, but good design, data, and concepts apply anywhere.

 

These questions together add up to what is frequently referred to as a “Concept” or “Design” Document – but really it is just a set of questions that people have about any endeavor. Put even more simply what they usually want to know is

Global:

  • “Would you spend your own money on this?”
  • “Would you do this yourself?”

Specific:

  • “What are you doing?”
  • “Why are you doing it?”
  • “How much is it going to cost?”
  • “How will I benefit?”
  • “How are you going to do it?”
  • “When are you going to be done?”
  • “What is going to stop you from getting it done on time?”
  • “If you have problems when are we going to know whether we should stop trying to do it”
  • and so forth.

Keeping the language clear, concise, simple, and universally understandable is the hardest part. Avoid technical terms and instead remember to write from the perspective of someone who knows very little about that thing and wants to quickly and easily learn. That is your audience. Especially don’t write from your own perspective, or from someone who is like you and already knows the subject, that person doesn’t even need such a doc.

For discussion/background see this post.

References: heavily adapted from, but inspired by, 37 Signal’s Book Rework “When to Quit” Chapter. Great set of graphics from this book here.

 

Design Tools

Design Tools (CC2 – Paul Stein – Original Image: https://flic.kr/p/qhsUF)

Breaking the Conference Enthusiasm-Cynicism Cycle

Conferences are a great place to reignite/rekindle the passion for one’s job.  Not only are the speakers passionate, inspirational, and engaging, but they also often have straightforward and concrete ideas for how to get real work done better and easier.  There is a positive knowledge and attitude transference that takes place and true feelings that “those are really good ideas,” “they did it and so can we,” and “let’s go home and implement that.”

But just as easy as it is to get fired up and excited to try new ideas, it can be just as easy to fall back into old patterns of behavior.  Those positive feelings diffuse, dissipate, and attenuate.  What is quickly learned can be just as quickly and easily forgotten when not put into active practice.

But is there some way to break this Enthusiasm-Cynicism cycle? Is there some way to move from learning toward changing? It is the classic problem of how do you go from learning anything toward really changing behavior.

Here is just one idea/suggestion where conferences are concerned. That real change as a result of attending a conference is possible, but it takes more effort than simply attending a conference. The people who were sent to the conference must be prepared to put in some effort when they get back. To repay their organizations that sent them, the attendees should be compelled to give their own presentations when they get back. In these they should provide a quick abstract of the most important things they learned (i.e. not just a raw dump of everything, but a few, most useful things to them). Then they should suggest at least three (3) things that their organizations should change as a result.  From this can flow a group consensus, a plan for change, concrete tasks, and some agreed-upon vision for getting the typical organization inertia moving and transforming.

Then maybe the next time that conference comes along next year, you’ll remember some of the positive changes and concrete by-products that resulted from last time and feel even better about the investment.

Image

Rethinking College

I really like it when people actually stop to think about and question long-held assumptions. Certainly one of these assumptions is that “you should go to college / going to college is always good for you.”

To my knowledge, there are only 2 people in my memory who have challenged this widely-held belief. One was Woody Allen in the movie Annie Hall when he quips “Everything our parents said was good for you is bad: sun, milk, red meat…college.”

The second was Google’s head of “People Operations” Laszlo Bock who was profiled in a recent Thomas Friedman opinion article in the New York Times and several others that built upon this article. My favorite Bock quote was that too many colleges “don’t deliver on what they promise. You generate a ton of debt, you don’t learn the most useful things for your life. It’s [just] an extended adolescence.”

We’ve long suspected that the inputs to college in terms of time, money, effort, and brain cells don’t often meet the outputs we seek in terms of knowledge, work ethic, creativity, and many other important character attributes. Now, companies seem to be realizing this as well.  As Friedman points out that Google “has so much talent it can afford to look beyond traditional metrics” but I suspect that Google is not the only company to come to this realization about college.

People who truly seek to develop themselves might do better to look somewhere else – the military or volunteer opportunities being just 2 examples. We need to change the goal and assumption that merely “going to college” is enough or even that it is always beneficial. Instead we need to restate and remember that the true objective and real end goal is to “become as smart, educated, and industrious as you can be.” Unfortunately college, as it is currently conceived and executed, is probably not where this is going to happen.