Friday, January 9, 2015

Preconceptions of Architects

"Science progresses best when observations force us to alter our preconceptions." --Vera Rubin

Been doing a lot of reading, been doing a lot of thinking. Having moved to a new company, I'm seeing my role in a different light, which is expected. Being the company's first architect, helping better define the role, and starting to work with development teams who are not used to working with an architect has really gotten me thinking. And reading some more.

I've read a lot of concerns about architects. Concerns that surprised me because they haven't been my experience, so I'm a little curious if these concerns are holdovers from days gone by (or at least going by) or if they are still relevant concerns. Either way, since the concerns are still talked about, I see a lot of value in looking at them and learning from them.

Architects are Ivory Tower Theorists

I've run into this before, and for good reasons. This is one have seen as a problem- designs getting passed on and the architect disappearing. Now, the disappearing act was often due to the fact that another effort had been dropped on an architect in a sorely understaffed group, but that doesn't mean the perception doesn't need changing.

Architects value theory over practicality

I'm kind of split on this one. There's a fine line here. Architects have to take the long view. I've sometimes said that I'm not working on this project, I'm working on the next one for this product. On the other hand, strict adherence to OO theory and complete Protected Variation (If indeed there is such a thing) are worthless if you can't get the project out the door. One of the biggest challenges of my career has been justifying a design that takes into account change that only might happen. I've found that YAGNI is a moving target.

Architects over complicate everything

Kind of an extension of number 2, but it goes a bit farther. A former manager of mine once said that an elegant design is one that makes the solution seem simple to the point of obviousness. I've often told developers that if I have to answer more than two clarifying questions about my design, then I made it too complicated.

So, what's the answer? I'm a pretty big believer in the idea that there isn't a "The" answer to much of anything, but I've been mulling over one answer. 

Architecture is an Agile project with the development team.

The parallels hit me recently. We provide a product for developers and should interact with them under the same principles under which developers interact with the business on a project.

Constant interaction

A sure sign that something has gone off the rails is an architect not knowing who is implementing a design. Just as an Agile development project requires constant communication with the client, so should we have constant communication and feedback from developers. A good development team doesn't need low-level guidance, be it from an architect, manager, or anyone else. But if the development team can't give feedback to the architect, then one of two things happen. Either they implement a flawed design or they ignore the design. Toss a coin as to which will cause more problems.

This doesn't mean an architect always has to incorporate developer feedback into the design. Sometimes you just have to say "No, this is the way we have to do it". I've done that once. Ever.

Factum non dictum

Deeds, not words. While thinking things through is important, even mandatory, at some point you have to act. And that point should be sooner, rather than later. Action is a funny thing. I've found that acting refines my thinking faster than thinking does. I've also found that action breeds more action. When I'm providing designs, rather than thinking about them, I get feedback faster (See the last heading) and thus work more efficiently.

But this isn't just about translating thoughts to deeds. How does one "act" as an architect? Over the years, I've come to three methods of communication:
  1. For simple things, talk to the developers. More than that isn't necessary if things are simple. "We have a web service that manages this functionality. Let's use that rather than developing a new library." "Let's use SSIS for this task"
  2. For moderately complex projects, I'll go ahead and use UML, but only if the resulting diagram doesn't look like a spider threw up a Visio diagram. If I have to actually follow a line with my finger to see what elements it connects, UML isn't helpful.
  3. Code is best communicated using code. There's a reason we call them "Languages" and there's a reason we have the phrase "Lost in the translation". With some things, I'll create a library with stubbed classes and a few examples based on project use cases and acceptance criteria. I don't mean this as a final design to be carved in stone, but rather a communication of a thought using a language natural to the discussion.

They don't work for you, you don't work for them

Developers and Architects are two sides of a coin. And while Architects may be used to giving guidance and oversight to developers, we sometimes forget that developers can, and should, give guidance and oversight to Architects.

In his book Software Architecture for Developers, Simon Brown compares Architects to Master Masons, responsible for design and oversight of the work and the workers. I think there's a lot of truth to that, but that's just one part of the relationship. Architects, I've found, love to talk theory. I've spent hours comparing design patterns, arguing the possible effects of a given DI Framework, or just whether or not a particular class should be considered an Interface or an Abstract class. Which is all a heck of a lot of fun. But if discussion hinders progress then the development team has the oversight, and even the responsibility, to say "Knock it off and deliver something already!"

Check your ego at the door

Fortunately, there's one thing that makes this all far easier to manage. In a good development department, everyone's a professional working towards the successful delivery of a quality product. That goes a long way. If the development team accepts the realities of an architect and the architect accepts the realities of practical software development, then it's highly unlikely there will be significant problems. Which begs the question, when conflict arises am I the one holding too tightly to my ideas or not communicating them well? Part of why I'm writing this is to remind myself to ask these questions of myself.

Thursday, September 11, 2014

The Tipping Point

"You can push that car just a little too far any Sunday afternoon. And if you break your neck in some damnfool wreck, they forget about you soon." --Charlie Daniels, "Stroker Ace"

I generally prefer to work at small to midsize companies. The reasoning is fairly simple, too. I like flexibility. Not a complete lack of defined policies, mind you. Policies are important. They give companies a road map for, if not efficiency, then at least predictable inefficiency. But smaller companies tend to have the flexibility to know when you need to stray off the beaten path. Large companies do not. And there's a certain logic behind that. The more you do, the more you rely on that predictability. Policies have saved my neck a time or two. Being able to say "I can't start this effort because our policies have not been followed" has forced projects to refine requirements and has gone a long way to prevent train wrecks. But there's a flip side, too.

At larger companies, it's harder to change policies that either no longer fit, or need refinement from the original draft in order to produce the intended result. There's also more risk in proposing new policies, I think. There generally tend to be more people that need convincing, which tends to mean more people that don't want to "Change what has been working for us". It often comes to a point where it's easier to just live with the inefficiency than try to change it. Or worse, at least in some ways, ignore policy and try not to get caught.

Okay. So far, I haven't told anyone something they don't know. This is one of the factors that need to be weighed when deciding whether or not to accept an offer or to leave a company. It's, hopefully, one of the factors you investigate when interviewing a company. As an aside, please note that I didn't say "interviewing with a company." You're as much deciding whether or not to offer them your services as they are offering you a position. Never forget, you're a contractor.

The point is, while working for smaller companies, I've noticed a reoccurring phenomenon, which I've started calling The Tipping Point. As smaller companies grow, they start to take on more work and start to do more. At this point, I have observed two results.

If the company does not at least have some policies guiding their work, the company tends to collapse. There comes a time when it's simply too late to gain control of source code, whether because nothing is in source control or there's no structure. When it's simply too late to implement good project policies because stakeholders aren't interested in becoming properly involved in projects and that disinterest is too entrenched to change. When projects are dangerous to deploy because no one knows what anyone else is doing. At this point, while the company may struggle on, it's no longer possible to fix the problems, and the only smart move is to leave.

The second result I've observed usually happens when there are a modicum of policies in place, and is usually hastened by bringing in An Expert. Perhaps a new CIO, perhaps a contractor. The buildup, again in my observations, tends to start slowly. No deploying projects without communicating with other groups. Nothing terrible there. Common sense, in fact. Issues, bugs, and defects need to be logged. Again- why would you not? And we need to get a sense of how much we're spending on projects, so we need people to log time spend on projects. Not my favorite activity, but I can't deny the importance.

But then things grow. Communicating deployments becomes getting signoff from other groups before deploying. The bug tracking system becomes a full-on change management system designed to integrate with every step of any process. Except yours, inevitably. Rather than turning in time tracking spreadsheets, either a web app gets build, or you're to use a built-in feature of the change management system.

Finally, comes the tipping point. I wish I could say this is an exaggeration, but in one case, I was entering time into an application that had a database lookup for projects, yet my projects never seemed to show up. I also had to email the same to my manager. The time tracker was in half hour increments, but my manager wanted 15-minute increments. Every change, even to dev environments, needed to be entered into five different systems (again- not exaggerating) and cleared in a bi-weekly Change Control Board meeting.

And all this doesn't even take into account well-documented problems when you mix in an Expert Scrum Consultant. I think I've made my opinions on the subject pretty clear, but it's pointless to deny what often happens when Scrum policies get blindly applied. And that's the problem- policies getting blindly applied. The "Monkey See Monkey Do" style of "Best Practices".

It's a rare gem when you find an organization with the self-discipline to recognize a policy that needs refining or simply removed. Or temporarily ignored on a non-precedential basis. A good set of policies are a balancing act. Too many and you get buried under their weight. Too few and you get buried under your own weight. That's The Tipping Point.

Wednesday, May 14, 2014

Dear Recruiters

Start with what is right rather than what is acceptable." --Franz Kafka

An open letter to recruiters. Mainly recruiters for software developers, but I suspect much of these are reasonable requests for all sectors.
  1. Please stop saying "Leading provider of". Sure- you want to give the idea that your client is A Major Player. Fine. All good. But using rehashed buzzwords doesn't convey that idea. The phrase is like the paintings in a hotel room. If you even notice them, they have no real meaning. Instead, tell me why your client leads their industry. What have they accomplished? How do they lead? Is it through use of new technology? New innovations? Say something meaningful. Something that will have an impact.
  2. Please stop telling me how many years your client has been in business. This may be useful information for clients, but potential employees aren't looking to retain their services. They're looking for a culture that fits. Generally, the amount of time a company has been in existence is irrelevant. Instead, talk about the culture. Not everyone wants to wear a suit and tie and interact with a rigid corporate structure. But not everyone wants to work in shorts and sandals, sitting on a bean bag, and walking into a Director's office for casual conversation. Laying this out will help find candidates that are a good fit for the company.
  3. Proofread your communications. Twice. When I see "I think you'd be a good fit for [Job Description]", I delete the email. Same with blatant misspellings. Anymore, any text entry application comes with an automatic spell checker.
  4. Read the resume. The most recent position is where your candidate has moved in his career and it's reasonable to think that that the position on purpose. If your contact is in a leadership, planning, or strategy position, it's probably a waste of time to offer direct development work. Your contact has moved on to something else and it's fair to assume that, barring unemployment, moving back isn't likely to happen.
  5. Be specific. "Maintaining large applications" or "Excellent communication skills" doesn't tell me anything. Again, these are hotel room paintings. What I want is a good snapshot of my day-to-day activities. Does "Sr. Application Developer" mean "Application Developer with a lot of experience"? Does it mean "Responsible for the work of a development team"? If I don't know, I'm less likely to take a chance. And that's exactly what you're looking for. Someone who will take a chance on your job offering being better than the current one.
  6. This is likely somewhat out of your control, but stop with the "X years of experience". While I realize that your client is telling you that, under the misapprehension that years of experience is an accurate measure of anything, you shouldn't have to tell that to candidates. If you can't tell from the resume how many years of experience the candidate has in the necessary technologies, then the resume has been badly written.
  7. Same with this "Degree needed" or "Degree or relevant experience needed" silliness. Aside from this not being any measure of anything important, it's pointless to include in a communication to a specific candidate. If your candidate doesn't have the necessary degree, don't bother. Likewise with "Degree or relevant experience". If your candidate doesn't have either, they clearly aren't a good fit.
So, what's the bottom line here? Much like the fact that a good candidate needs to stand out in order to be seen as a good candidate, recruiters need to stand out in order to be seen as a good recruiter. You can't afford to be a carbon copy of everyone else. You can't just be hotel room art, and you can't hand over a vague description with ubiquitous buzzwords and expect to spark any interest. Instead, you need to capture the candidate's attention. You do this through clear and concise communication of what your client is looking for. You do this by standing out.

A thought to keep in mind. All the advice recruiters give to job seekers about how they present themselves through resumes and interviews? That should apply to your communications with candidates. Especially your first contact.

Tuesday, March 25, 2014

Agile Isn't Dead

"Best practices are useful reference points, but they must come with a warning label : The more you rely on external intelligence, the less you will value an internal idea." ― Gyan Nagpal, Talent Economics: The Fine Line Between Winning and Losing the Global War for Talent

Agile isn't dead. It's not even on life support. However, to extend an analogy that everyone in the world should stop using, it does have a couple of CAT scan anomalies it should get checked out.. I've read a few tech opinion pieces to the contrary lately, so I thought I'd throw my hat in the ring.

+Hayim Makabee wrote an excellent piece on the subject, but one that I feel missed the mark somewhat. Jim Bird wrote on a finer grained level on the subject, and if you take them together an interesting picture starts to emerge. Starting with Jim Bird's piece, he lists several "Agile" practices that aren't needed. Skipping by a few points on which I disagree, his overall point is sound. Not all common practices are necessary. Hayim Makabee takes this a step further, rightly pointing out how "Agile" or "Scrum" consultants "over-simplify the software development process and underestimate the real complexity of building software systems". And I'm not really arguing that this "one size fits all" approach is a problem. I believe that the problem's source hasn't quite come out yet.

In short, the problem is IT decision makers. Not Agile, which is just a set of principles. Not Agile consultants, who are just selling a service people have asked for. And while we can discuss the moral culpability of someone "just selling a service", the fact of the matter is that people are buying the service. And those people are IT decision makers in pursuit of a concept that has made me cringe for some time now. Best Practices. "Best practices" are like the Dark Side of the Force. Quick, simple, seductive, and once you walk down it's path, forever will it dominate your destiny. "Best Practice" is shorthand for "What everyone else is doing", and while it's the sort of thing one ought to take into account, I've seen enterprise after enterprise implement iron-clad procedures based solely on "Best Practices", or rather "Just do what the neighbors across the street are doing". And before too long, you have Citogenesis, that curious phenomena where people think something is correct because people think something is correct.

Agile is a set of principles, and as far as principles go, they're pretty darn good. Agile isn't dead because these principles are still the best way to create software. But it really needs that dark spot checked out.

Sunday, February 9, 2014

Life is Agile

"It's not what happens to you, but how you react to it that matters" --Epictetus

I'd like to pose a question to any parents reading this. When your child was born did you plan out every detail of your child's life? Did you attempt to account for every problem and develop a contingency plan before even leaving the hospital?  Do you parent in a vacuum, having no contact with other parents?

Similar question to those of you with active careers, be it in the job market or at home. Yes- being an at-home parent is a career. Did you plan out every step of your career before you began working? Do you work without interaction with others in your career? Did you plan for every problem to the most minute detail?

Of course not. To approach such a major endeavor in life is more like planning to fail. And this is why Agile is the only way to successfully complete a software development project of any consequential size. Because it mimics human behavior and human capabilities. At it's core, the Agile methodology is an admission that you can only do so much to plan for the future. It's a system built on the foundation of communication with others. It does not merely recommend regular and effective communication, it states that failing to do so will cause overall failure. It is built around doing what you need to now, while keeping an eye on the future. Similar to how you eat an elephant (one bite at a time), so do we manage our lives. Why should we assume that managing a development project should run so completely contrary to our fundamental behavior?

The converse is also true. It's been a very long time since I've had to defend Agile vs. Waterfall/BDUF. The reason appears very straightforward- the proof is in the doing. Agile has proven itself. It's not theoretically better, it simply is.

How, then, can we extrapolate this to our lives? Should you find yourself working at a company where you have no future, what do you do? Do you scrap the idea of working at your best capacity while you look for another job? Agile says differently in that a development team has the discipline to finish a development sprint, i.e. the work in front of them.

If you want something in your career, do you just keep working and hoping it happens? One of the foundations of Agile is communication. Do we keep grinding and hope, or do we approach others for advice? And then do we approach management and clearly communicate what we want?

Life is Agile is life. The lessons we learn from each can be applied to the other.

Monday, December 2, 2013 failures in leadership

"Good management consists in showing average people how to do the work of superior people." --John D. Rockefeller

"Good management is the art of making problems so interesting and their solutions so constructive that everyone wants to get to work and deal with them." --Paul Hawken

Yep. I'm back at this well. Partially because it's a great way to boost hits (I don't use ads, but I do have an ego) but mostly because I've been there. Not in a project this size, but I've lived the nightmare. Maybe someone that can affect this boondoggle
reads this and listens. Likely not. I have an ego, but I'm a pretty small fish. More important to me is that the developers and IT staff affected by projects like this understand the failings so that they know when to update their resume.

This one is coming from a New York Times article titled Inside the Race to Rescue a Health Care Site, and Obama. And again, whether Ms. Stolberg and Mr. Shear realize it, they paint a picture familiar to many IT veterans.

Failures of Testing

I've written about the technical failures of the development teams but what has been written in this article serves to underscore something all development teams know, but fewer do. Testing. From the article:
"To do that, they would have to take charge of a project that, they would come to discover, had never been fully tested and was flailing in part because of the Medicare agency’s decision not to hire a "systems integrator" that could coordinate its complex parts." 
"The website had barely been tested before it went live, so a large number of software and hardware defects had not been uncovered." 
"'There’s so much wrong, you just don’t know what’s broken until you get a lot more of it fixed,' Mark Bertolini, the chief executive of Aetna, said on CNBC."
Regression testing. Unit testing. User Acceptance testing. I can't think of a better way to talk about the dangers of not budgeting time to properly test your project.
"In Herndon, as engineers tried to come to grips with repeated crashes, a host of problems were becoming apparent: inadequate capacity in its data center and sloppy computer code, partly the result of rushed work amid the rapidly changing specifications issued by the government."
Code reviews and proper architecture concern would have prevented the "sloppy code" issue. The rest of this segueways nicely into my major point, thought.

Failure to understand a software development project

Clearly, project management didn't know how to manage a large-scale project. I've said before that the evidence could not be clearer that this project was managed Waterfall-style. And while the far-preferable Agile development style can also struggle with changing requirements, the iterative workflow, combined with constant checkpoints with the business stakeholders allows for better options for dealing with the fact of life that is spec change. Here are a few examples from my playbook:

"No, we will not change specifications in mid-sprint. If you want this change, submit it to the Icebox and give it a priority. We will then do the design and estimation work and add it to a future sprint."

"No. This is a two week sprint. We will not finish early. We will not rush. We have a planned amount of work that will take two weeks to deliver properly."

"No, we will not add to this sprint. The sprint covers an amount of work that can be accurately delivered in two weeks."

"No, we will not include this work into a sprint until there is proper user acceptance criteria attached. The delivered code will then conform to the acceptance criteria listed. No more, no less. I'm here to help you write good acceptance criteria."

Enforcing this kind of project discipline is crucial. It should be well-communicated up front. Everyone should know what an iceberg is. And once the expectation is set, that expectation is enforced. But even with that, the problem runs far deeper. Some quotes from the article really chilled me:
"Out of that tense Oval Office meeting grew a frantic effort aimed at rescuing not only the insurance portal and Mr. Obama’s credibility, but also the Democratic philosophy that an activist government can solve big, complex social problems." 
"'We’re about to make some history,' she (Ms. Sebelius,) said.
"...reveals an insular White House that did not initially appreciate the magnitude of its self-inflicted wounds"
As any regular readers know, my overall philosophy comes from Marcus Aurelius:
“This, what is it in itself, and by itself, according to its proper constitution? What is the substance of it? What is the matter, or proper use? What is the form, or efficient cause? What is it for in this world, and how long will it abide? Thus must thou examine all things that present themselves unto thee.”  
By itself and in its proper constitution, is a website that allows people to purchase health insurance. It is not a justification of a political philosophy. It's not about making history. Those are incidental. You cannot make good decisions if you don't understand the context for those decisions. You can't make good decisions about a development project if you see it as anything other than a software development project. And don't think for a second that minimizes its importance somehow. Most developers I know care a good deal more for their code than they do your politics. But if management mistakenly sees a project as some kind of ideological movement or as setting their legacy then they aren't making project management decisions.

Management culture

Finally, what may be the worst failing of the management of this project. It's culture. The standards management sets for its operations. The only place I've ever heard of management leading so poorly is in Dilbert. For example:
"For weeks, aides to Ms. Sebelius had expressed frustration with Mr. McDonough, mocking his “countdown calendar,” which they viewed as an example of micromanagement."
Mocking other stakeholders. Ignoring, for a moment, the notion of expecting professionals to not act like spoiled children, why was this behavior considered acceptable? Management sets the standard for how people act. A good manager understands this. A good manager sets an expectation of professionalism. Complaining is one thing. Open mocking should be the sort of thing people are embarrassed to do, or even to listen to.
"Contractors responsible for different parts of the portal barely talked to one another, hoping to avoid blame."
There's enough written about how a management culture of blame creates a toxic environment. Problems aren't addressed. People pass the buck rather than address problems. The concern is to not be left holding the bag, rather than making sure work is done well. Fear does not create quality. And clearly, this is not known here.
 "Mr. Obama, meanwhile, was under assault. After years of telling Americans, “If you like your insurance plan, you can keep it,” he was being accused of lying. On the night of Oct. 28, Ms. Jarrett, one of Mr. Obama’s closest confidantes and a guardian of his personal credibility, took to Twitter to defend him — and to shift the blame. 
“FACT,” she wrote. “Nothing in #Obamacare forces people out of their health plans. No change is required unless insurance companies change existing plans.”
The tweet touched a nerve; it was not the first time the Obama White House had used the insurance industry as a scapegoat. Ms. Ignagni’s (chief executive of America’s Health Insurance Plans,) members were furious. “Here it comes — we knew it would happen,” one executive recalled thinking."
 The Obama administration built support for the ACA by building hostility to the insurance industry, with whom they must now work. So, in essence, the Obama Administration has taken every opportunity to publicly condemn the insurance industry and is now relying on that same industry to launch not only it's centerpiece website, but the validation of their political philosophy. A management team that does not treat their vendors with respect will find themselves very lonely once they need their vendors. UnitedHealth and CIGNA have already "mostly shied away from the online marketplace" (From the article). To assume this has nothing to do with the administration's clear contempt for their vendors is folly.

I have a difficult time summing up my shock at the sheer number of leadership failures involved here. Not just in knowing how to run a software development project- clearly Medicare and the Dept. of Health and Human Services considered this a "Fire and Forget" project and that they were absolved of all responsibility to be involved once the project started. More disturbing, though, is the culture that management allows. Childish behavior and finger-pointing should not be acceptable. And that attitude starts from the top.

Wednesday, November 13, 2013

Dedication and Vision

"If you do not have an absolutely clear vision of something, where you can follow the light to the end of the tunnel, then it doesn't matter whether you're bold or cowardly, or whether you're stupid or intelligent. Doesn't get you anywhere." --Werner Herzog

Short article today.

Ran across something that really made me think about software development projects. Three developers in San Francisco built an alternative to in two weeks.

Two weeks.

Now, you can't purchase- just search and compare rates and plans. But again. Two weeks.

No complicated procurement process. No contractors. Certainly less than hundreds of millions of dollars. Just three dedicated guys with a clear vision.

A G+ friend of mine +Chaka Hamilton took this a step further:
I bet if the gov offered a darpa style challenge, they'd have a working website in half the time, and cost. They obviously have learned nothing from open source / crowd source community.
 Indeed. What if they had.