Technical Leadership Is Leadership

Being a technical leader can involve a number of challenges.  Between outside forces, long- and short-term pressures, legacy systems, and complex problems an architect, lead developer, or development manager has a lot on his plate.

Many of the most skilled programmers are comfortable with those kinds of challenges.  For a lot of technical people that's the only kind of problem with which you are comfortable.  Whether, like me, you are arrogant and demanding or, like many others, you are shy and reserved, there is a decent chance that you don't count people skills among your strongest.

Yet the technical challenges only represent half of the problems facing a technical leader.  To be truly effective, you have to be a leader of people in addition to a setter of technical direction.  That is, unless you want to do everything yourself.

I'm not saying that every kind of management problem necessarily rests on the shoulders of a technical leader.  I do believe, however, that empowering the people you work with to make better technical decisions on their own will have an enormous impact on your effectiveness as a technical leader.

For instance, I recently wrote an article for InformIT that touches on the subject, entitled Five Ways to Optimize Encapsulation in Your Software Architecture.  In most scenarios, every single step requires someone to not just be a leader in the area of design and architecture but also a leader of men.

For me, this is the biggest kind of challenge available in the software world.  It's hard and rewarding.  Sure, there are things that are harder - like trying to maintain really terrible legacy code - but those things aren't as rewarding because so little is accomplished in exchange for so much energy.  There are areas where I have more success - like maintaining code that was written the modern way - but that's not as rewarding because so little energy was exchanged for the benefit obtained.

Building up people's skills, guiding them, helping them grow, and influencing their decision making meets all my challenge criteria.  At least, it does now that I've become interested in that level of challenge.  It requires patience, understanding, and a close approximation of empathy - things that don't come easily to me.  On the other hand, in exchange for the enormous effort involved, you get enormous value.

The worst likely case is that you fail and nothing happens.  In the software industry, that's actually a pretty good bad scenario.  Once you develop your mentoring and leadership skills, the most likely case is that you will permanently modify how effective someone is as a programmer, building up a portfolio of recurring dividends over time.  Sometimes, you will help someone else become a true technical leader, improving the rate at which dividends are increased.

The rate of return on this kind of effort is very, very high.  For most of us, there's nothing more rewarding than hard work with a high rate of return.  So, the next time you're considering your position as a technical leader, try to think about how much time you spend leading people not just products.

Test-Driven Architecture Article Published

The article my friend, Mike Brown, and I wrote has been published.  The topic is how to apply test-driven development to architecture.  You can find it here.

Another Article Submitted

I've submitted a third article about architecture to InformIT.  This will probably be my last one for a while.  I want to go back to focusing on the database stuff.  This most recent article has a moderately interesting story.

It started out as a position statement: Encapsulation is the most important thing in architecture.  Encapsulation is already the most important thing in any software development effort, so that ended up coming off a little pompous.

I then rewrote it as something that addressed the root motivation which underlies encapsulation: longevity.  That article ended up being interesting but it didn't talk enough about encapsulation, which was the original point of the original article.

I settled on the working title "Five Tips to Maximize Encapsulation in Your Architecture" and I have received word that it will be published on February 20^th, 2014.

I'll post a link when it is published.

On my way to the @agilepdx meeting tonight

The weather is a little dicey but we have enough of a head start to make it on time.

I will post a link to the slides and sample code tonight after the talk.

Also: While today's talk is not a sales pitch, I will have some books on hand should anyone want to buy one.

I Got on Some Top 100 Lists!

I just wanted to document that, at some point in my life, something I wrote broke #100,000 in paid books and was on the top 100 list in three paid categories.

At one point, this was one the above page

DataClass 3 - Transparent Data Model

One of my goals with DataClass 3 is to have a transparent data model that describes a class of data store without any coupling to a particular syntax.  This serves a couple purposes.

One reason is to better support automation.  With an API and a clear XML format, people can do all kinds of things.

Another reason is to create a natural and strong division between syntax and compiler.  If I do that, I can develop a few different languages.  That way, people who think curly braces are what slow them down can have a language that uses white space to define blocks and sane people can use curly braces or whatever.

Then there is the main force driving this design decision.  Having a clean, platform-independent way of expressing a database design allows me to write, say, a Java client that can explore a database class definition file and expose its structure to Eclipse.  I can do that about as easily as I could with a Visual Studio extensions.

There is a consequence to this design.  While the XML format is theoretically human-editable, it is not intended to be the primary means of expressing a data class.  I'm still committed to having a domain-specific language for that purpose.  So, whereas DataConstructor and the sample code for my book use XML as the primary format, I have no intention of supporting that in DataClass 3.

Test-Driven Database Development: Unlocking Agility Complete; on to DataClass 3

After a year of work on my book, I'm ready for a break.

Just kidding.  Now that the book is done, it's time to write DataClass 3.  How will it be different from DataClass or DataConstructor?  A lot of ways, actually.  I'm not going to plan everything out right here and now.  That wouldn't be very in character, would it?  However, I do have some high-level goals I want to meet.  Here they are in no particular order.

• Add a transparent data model
• Expose parsing capabilities for automation
• Restore a feature from DataConstructor: support for other kinds of data (XML, objects, etc.)
• Extension point for client platforms
• Extension point for database platforms
• First class support for the obvious structures in a database (tables, views, stored procedures, etc.)
• Inferred design

There are a bunch of other "nice to have" features I intend to implement later but for the initial rewrite, I'll stick with that scope.  Sadly, yes, you read correctly.  Once every two years, I run a little experiment to verify that people who think mocking is bad are crazy.  DataClass 2 was that experiment.  It's easier to rewrite it the right way with these new goals than to try and change directions with that code base.

There are other things I'm changing, too.  Most notably, I'm changing the profit model for DataClass.  The compiler and API will be freeware.  Anyone can download it and use it for whatever purpose they may have.  Then I'm going to write extensions for Visual Studio, Eclipse, and maybe IntelliJ IDEA.

I'll delve more into each topic in a separate entry later as I have time.

Special Thanks: Max Guernsey, Jr.

Test-Driven Database Development: Unlocking Agility is almost on the shelves, now, and there is one last person I would like to thank: my father.

Of course, both my parents are responsible for my existence and contributed to my development as a human being.

My father, however, played an especially strong role in my growth as a software developer.  I learned many of the fundamentals from him, either by way of direct instruction or indirectly through conversation.  So thanks, dad, for getting me started in the career path I'm on today.

Agile Database Development Resources

I've started tracking the list of Agile Database Development Resources I know about on a dedicated page.

The two most recent additions will be my recently published article on InformIT - Ten Tips for Constructing an Agile Database Development Environment that Works - and my related upcoming book.

Looking for Venues to Give a Talk on Test-Driven Database Development

In the very near future, Addison-Wesley will be publishing my new book, Test-Driven Database Development: Unlocking Agility.  Recently, I did a talk at Better Software East on the same topic.  I would like to re-deliver that talk at a number of locations in the United States and I'm looking for companies or user groups that are willing to host a ninety-minute talk on the topic of test-driven database development.  I'm trying to do these talks at times when I'm already going to be in a city.

You can find the list of cities and available dates here.  A large date range means I intend to travel to a city in that date range but have not yet nailed down the dates.  In that case, I will try to work around any bookings I make.  A small date range means I have a hard travel date and will need to fit such a talk into that schedule.

Contact me via email if you have anything available or any ideas.

Special Thanks: Alan Shalloway

Well, it looks like the release of Test-Driven Database Development: Unlocking Agility is less than a week away now.

I'd like to thank the guy who is in charge of the Net Objectives Lean-Agile Series: Alan Shalloway.  Not just for inviting me to publish in the series but for helping shape me as a professional.

It's probably hard for you to imagine but the warm, fuzzy, forgiving, and benevolent Max Guernsey you know was not always that way. I used to be a lot meaner and a lot less tolerant of foolishness.  Al, among other people, took the time to guide me to a more functional way of dealing with people.  I think there's some irony in the fact that he taught me to be a little better at dealing with people by helping me value other people getting a little better at programming.

So thanks, Al, for your patient guidance and mentorship.  I'm certainly not done getting better at dealing with people but I am started and you played a big role in that.

Different Forces Are No Excuse for Bad Practices

Encapsulating construction is not optional.  It is a mandatory part of good design.  The reason simple and easily conveyed.  If instantiation is encapsulated, resistance to changing what concrete type is used is low.  If sprinkled throughout a code base, that resistance is high.

One of the most important kinds of changes in this family is promoting a concrete class to an abstraction, moving the behavior to a new concrete class, and changing construction logic to use the new concrete class.  Being able to perform that operation allows you to defer the creation of an abstraction until there is actual variation to encapsulate.

This concept was popularized in modern languages like Java and C#.  A typical implementation is as follows:

public class IsConcreteForNow {
  // nobody can create this directly
  private IsConcreteForNow() { }

  // force everyone to get it indirectly
  public static IsConcreteForNow GetInstance() {
    return new IsConcreteFornow();
  }
}

C++ programmers are often resistant to encapsulation of construction when presented with a "literal" translation as follows:

class IsConcreteForNow {
private:
  IsConcreteFornow() { }

public:
  IsConcreteForNow* getInstance() { return new IsConcreteForNow(); }
}

If you are a C++ programmer, it's probably already apparent why this is so objectionable.  To start doing such a thing demands that you put every object on the heap and give up stack instantiation forever.  That price seems too high to warrant the value.  It isn't too high but it seems that way to people who are accustomed to leveraging the stack for most of their short-lived objects.

When some French guy says he has a hangover, you don't translate that to "my hair hurts" or "I have wood mouth."  You translate the intended message, not the individual words.  Likewise, encapsulating construction should be translated so as to meet the need in the context of C++ without regard to how that need is met in other languages.

While C++ makes certain aspects of keeping objects on the heap a little more complex, it has a lot of cool tools that can help you in other ways.  For instance, it has the concept of a typedef, which allow you to (among other things) define how types relate to other types.  It also has a more powerful operator overloading mechanism than a lot of other languages.

These two things put together allow you to implement encapsulation of construction in a different, but still useful way as follows:

template<class T>;
class OnStack {
private:
  T core;
public:
  T* operator -> () { return &core; }
};

class IsConcreteForNow {
private:
  IsConcreteForNow() { }

public:
  typedef OnStack<IsConcreteForNow> TransientPointer;
  typedef IsConcreteForNow* PersistentPointer;

  static void CreateTransient(TransientPointer& toCreate) {
    // constructor already did the work
  }

  static void CreatePersistent(PersistentPointer& toCreate) {
    toCreate = new IsConcreteForNow();
  }

  static void DestroyPersistent(PersistentPointer& toDestroy) {
    delete toDestroy;    toDestroy = 0;
  }
};

Note how this implementation forces consumers of a class to go through its static instantiation methods while respecting the forces imposed by C++, namely the distinction between an object that should only live for a stack frame and one that should live longer than that.

This code can be consumed as follows:

IsConcreteForNow::TransientPointer transient;
IsConcreteForNow::CreateTransient(transient);

transient->DoSomething();

IsConcreteForNow::PersistentPointer persistent;
IsConcreteForNow::CreatePersistent(persistent);

persistent->DoSomething();

IsConcreteForNow::DestroyPersistent(persistent);

Later, should I decide that I need variation, I have lots of options.  If it is absolutely imperative that I create an object on the stack, I can go through all kinds of contortions to support that.  Otherwise,  I can simply switch my TransientPointer type over to being an auto pointer or something of that nature and instantiate the right type as needed.  I can make all of those changes without any effect whatsoever on my client code.

Encapsulating construction is something everyone should do with every class they write.  I've just shown you can do it with C++.  If you can do it in C++, you can do it in any language worth your attention.  If you are using a language that makes encapsulating construction seem hard then you either need to re-evaluate how you look at the forces in that language or you need to re-evaluate if that's the right language to use at all.

Special Thanks: Michael Brown (the non-criminal one)

In my quest to build my most recent book, Test-Driven Database Development: Unlocking Agility, there were many people who helped me.  One of those people is a recently acquired friend and colleague Michael Brown.

There are two Michael Browns with the same name and one of them is a criminal.  The other is not. I mean the one who is a computer programmer, not a criminal.  There are other distinguishing characteristics but none that make me laugh as hard when I remember them.

As much as it was useful to know which parts of the initial versions should never see the light of day, it was also extremely helpful to know which parts of what I was writing actually were of value.  Mike, your positive and open-minded attitude helped me with exactly that.

Of course, you gave me some constructive criticism as well - just like others gave me positive feedback.  However, I could tell what was really clicking by how excited you seemed to get over certain ideas.  I can think of at least one thing that was completely unclear and that I may very well have left out altogether if not for your response to it: the whole information-behavior-knowledge trinity.  There are countless many other examples, that don't immediately come to mind.

So, thank you, Mike.

Special Thanks: Scott L. Bain

On March 7^th, my latest book (Test-Driven Database Development: Unlocking Agility) will be on the shelves.  This was a large undertaking and some of my friends and colleagues played a major role.

I cannot think of anyone who had a more profound impact on the development of this book than Scott L. Bain, author of Emergent Design: The Evolutionary Nature of Professional Software Development.  Scott is both a friend and a colleague.

Part of the depth of Scott's influence stems from how far back it began.  Long ago, when dinosaurs roamed the Earth, I had an idea that seemed like it was the right thing to do but I couldn't figure out how to persuade more than one person at a time.

The problem was that I thought I had a software product and Scott helped me see that I actually had an educational product.  He got me interested in writing technical materials and in teaching other people how to do things I knew how to do.  This was a big leap from making software and expecting people to already know what they should do.

Part of the impact comes from Scott's skills at, and interest in, developing developers.  Before the Earth finished cooling, I was a good programmer but not yet a good software developer.  Scott's careful, patient, and wise guidance kept me on a path of discovery that put me where I am, today.

It's hard for me to even imagine what I would be like without his guidance, but I'm very much afraid that I would be sitting in some ivory tower hurling proclamations down upon the commoners and cleaving to impractical ideals like everything being hyper-configurable all the time.  You can see direct evidence of Scott's influence on my thinking about things like design in my book.

So a special thanks goes out to Scott Bain for his contribution to my book by way of contributing to my character.  Thank you.

Breaking Down Barriers to Agile Database Development

Having a cross-functional team that works together to solve a problem is a basic property of an agile development environment.  It's impossible to list all the things that can impede the development of an agile database environment.  There are, however, some particular scenarios worthy of note.

One common case, especially in smaller organizations, is that the person who works on the database design is also a programmer.  In that case, fostering a collaborative environment is probably not too difficult.  Don’t let people catch you talking to yourself too often, though.  They might decide you have cracked under the pressure.

Another scenario that is ever-increasing in its frequency is when you have an agile development team with a “database guy” or a “database gal.”  In this situation it is important for programmers and the “database folk” to work together.  However, it’s still not that hard.

The toughest nut to crack is when you have an organizational boundary between a team of programmers and one or more database people, and those database people serve not only as database developers but also as “gatekeepers” to some production databases.  Oftentimes, the gatekeepers are vehemently against anything agile as well as anything automated touching their jealously guarded database structures.

I’m not exactly known as some great builder of bridges.  I’m actually better known for my “scorched earth” manner of dealing with people who I see as “in the way.”

However, there is one trick that has worked for me on the rare occasions when I was able to take a deep breath and count to a thousand before opening my mouth.  That trick is giving the gatekeeper control over the new processes I want implemented.  Instead of persuading them to let me have the most agile thing I can possibly get, software development teams in control of database design, I settle for the next best thing.  I try to persuade the "database guy" to take on the test-driven development and and object-oriented design activities I want implemented.

An example would be trying to get them involved in things like writing transition tests.

People tend to want to do the right thing and, when they are doing the wrong thing, it’s usually because they don’t understand the negative impact.  The other major reason is fear of no longer being needed.  It’s not so important who implements good practices as it is that they are implemented.

Giving control over certain aspects of an agile database development process to someone who is already in control of the database development process often neutralizes both the major impediments to adoption.  The gatekeeper will be able to make sure things are done his way and can be assured that he will remain relevant while slowly growing more accustomed to the modern ways of doing things. 

Special Thanks: Seth McCarthy

As the hour of Test-Driven Database Development: Unlocking Agility draws nearer, I'm left with less to do and more time to reflect.  It was a lot of work and, no doubt, I did much of the work.  There are numerous people who have been in some way responsible for the current shape of the book.

One of those people is Seth McCarthy.  Seth is a friend I acquired upon moving to Central Oregon.  As a good friend, he offered to read early chapters of the book.

One thing that makes Seth unique as a friend is that he is not afraid to give harsh criticism when it is deserved.  For some people, I'm sure, that's a problem but for me it worked perfectly.  There's a reason that you won't see any of the original chapters if you read my book and most of it derives from Seth being willing to tell me I was pompous, long-winded and (worst of all) off topic.

Thanks, Seth, for being technically competent and forthright enough to spare me the abject failure the first incarnation of my book surely would have been.

Politicians and Leaders

I think I'm a pretty good leader.  I say that based on anecdotal evidence.  When I take up a charge, people tend to get behind me and we all work together to crush a problem.  That seems like leadership.

However, whenever I'm given any kind of management task, I tend to fail and I think I'm just now discovering why.

Management and leadership are perpendicular concepts.

Leadership is inspiring a bunch of people to do something, helping devise a strategy to do it, and participating in getting it done.  Leadership is about looking out for the people who are working with you toward a common end.  It is also about doing what needs to be done to make sure you and your team succeed.

By contrast, what we typically call "management" today, is none of those things.  That's not to say there aren't managers who are also leaders - there certainly are - but the tasks of management are about satisfying managers above you, tracking what's been done, and vying for resources on behalf of your team.

What we call "management" in America, today, is really "politics."  People who are successful managers are invariably good politicians and variably good at leadership.  It is a skill that is more about lobbying for the favor of "higher ups" than it is about getting those around you or beneath you to a goal.

My mind goes back to what my seventh grade French teacher said about math.  He said something along the lines of "Algebra is fine.  There's nothing wrong with it.  Well... I guess there is one thing wrong with it."  Then he hurled a handful of papers over his shoulder and shouted "You have to care what x is!"

That's how I feel about politics.  I don't care what people think of me.  To me, making people who can't do what I do or what the team I'm on could do feel warm and fuzzy about it seems like the biggest waste of time in the world.  Really, I think the evidence suggests I could give a flying fuck about making anyone feel warm and fuzzy if they haven't earned it.

So I'm coming to terms with the fact that the management path is not the one for me.  I may be a good leader - I think I am - but I am a terrible politician.

2012 Year in Review: Professional Life

One of the nicer things that happened this year was that things have started getting better at work.  A lot better.

2012 marks the year in which we stopped paying lip-service to making things better and we started doing it. I cannot go into the details of everything that was done for obvious reasons but we made some big strides in the quality of our product and how we target what is to be built and we made some real in-roads to tearing down long-standing impediments.  Those are both exciting developments.

As far as how we build things, we've made some major changes there.  Unit-test-driven development has all but completely infiltrated one office and is starting to take hold in others.  Resistance to acceptance-test-driven development is starting to falter; I imagine it will crumble in the next one to two years.

We've also become less resistant to rolling out process improvements in general as I imposed an "auto-rollback" system on the team and it did not rise up in revolt against it... or maybe they did but I and some other supporters were able to quell the rebellion.   Either way, things are getting better.  Most importantly: other members of the team are starting to impose their own process improvements.

Are things where they ought to be?  No.  They never are.

We're getting there but it's an act of supreme patience to allow things to unfold on their own schedule.

2012 in Review: Test-Driven Database Development

One of the big things for me in 2012 was the completion of my book, Test-Driven Database Development: Unlocking Agility.  While, technically, the book is not done as of the end of 2012, my part of it is complete.  The only task I will need to complete is approval of the final pages.  It's done enough that, if I drop dead right after completing this post, the book would still be released.

Even with friends who had already been there before warning me, even with a smaller publication under my belt, I was unprepared for the amount of work this would entail.  I spent much of 2011 and 2012 writing the book and, after that, there were numerous review and revision phases in which I had to participate.

A lot of authors, at this point, say "I wouldn't recommend it."  I am not one of those people.  Was it hard?  Sure.  Does that mean I wouldn't have done it, if I knew how much work was involved?  No.  It was an invaluable experience and, I imagine, the next one will be easier just by knowing how much work it entails.

Furthermore, the topic is, I believe, an important one.  If I really can help developers start making database design less of an impediment and more of a participant in Lean or Agile processes, then the time was well spent.

Not to mention that having a real book under my belt so early in my career can only have a positive influence on my professional life.  Anyway, this was a big deal for me and I want to thank everyone involved in making it happen, from the folks at Net Objectives and Addison-Wesley who green lit the project to all my friends and colleagues who have contributed directly or indirectly to the development of the book and the ideas it contains.

Happy New Year, End of Year Wrap Up

Well, everyone, the year is wrapping up right now.  For many, it's already over and 2013 has already begun.  For others, there are several hours to go.  Any way you slice it, now seems like a good time to do a year in review.  I know you are all super interested in my life.

The landmark events in my life for this year were as follows:

• finally got off my but and started self-publishing the Sleight of Mind series
• finished development of my book, Test-Driven Database Development
• moved into a new house out in the country
• getting some real traction in implementing test-driven development as well as other process improvements where I work

I'll drill into each of these in a subsequent post.