architecture

Everyone wants their software development projects to go well. Nobody wants their project to suck. And yet, the world is full of Software Development Projects That Suck! Why is that?

I’ve worked with about eighty different companies on their software development projects over the last thirty years or so. They’re all different, but not so different that some patterns don’t become apparent. So let’s talk about a few things that go wrong super commonly.

People don’t like long blog posts, so for right now here’s just one.

Persisting with a technical approach that doesn’t work.

Wow, this one is hard. You’re trying a new technology stack and engaging a big new project at the same time, and it’s harder than it looks. Maybe you find that a critical component is in pre-beta, or incompatible with your architecture, or totally missing.

You can prevent this by learning with small projects that carry low risk before you commit to the platform shift. If management insists on implementing a larger and riskier project before your team is really good at using the new platform, you need to push back. (Sometimes there is no substitute for courage and politics.)

If you find yourself in this particular kind of Suck already, you have two decent options.

One way is to get out of the new stack quickly. Start over. It hurts but it hurts less than going two years and having nothing really working. The obvious problem here is that if you weren’t able to persuade management not to put you in this particular jackpot in the first place, you probably won’t be able to persuade them to let you start over. (Once again, tech can’t solve your management problems.)

The other way is to get help. One time I saw a big web design company take on a non-trivial Sitecore project even though they didn’t have any Sitecore chops. That was going badly until they brought in a partner company that focuses hard on Sitecore development! I’m pretty sure the first company lost money on the project in the end, but it did get done and they avoided the bigger Suck of walking away from a multi-million-dollar fail.

Sometimes it’s you.

A lot of times it’s not the “stack” though, it’s you.

A pattern I see now and then is when developers get a little too ambitious, un-Agile, and try to solve some bigger problem than the project at hand. For example, I was on a team once that was developing a really small web application, not much more than a “Contact Us!” form, and it took four of us about six months.

Six. Months.

Because the lead person had a great architecture concept which we ended up calling “The Framework.” I don’t recall the details, but I think the gist of it was that he was implementing a data-driven content management system rather than straight up regular ASP.NET pages. Sort of like using WordPress for a site that didn’t need that much of a feature set… except he was busy actually inventing WordPress at the same time.

A long time ago I got stymied on a solo project when I attempted something a little similar. It was a reasonably normal parent-child-grandchild data entry application with a few neat user interface features. The platform (mid-1990s, CA-Visual Objects!) didn’t have a great standardized CRUD paradigm built in, so I tried to write one that was hyper-generalized and sort of clever about normalization.

Over a data store that was still ISAM tables. Yikes. It worked in theory!

What I’m getting at here is the Agile concept of doing today’s work today. Today you are implementing a Contact Us page. Today you are implementing a CRM front end. Today you are implementing a configuration monitor. You are not replacing WordPress! You are not creating a Framework for all future development!

Long story short, if the vendor platform was a bad choice, you need to get help with the platform or get out of the platform. If the internal architecture was a bad choice, you can set aside the “big ideas” and refocus on the original project as defined and let go of the architecture mistake.

What have you tried?

Comment and share! Have you had a Project That Sucks because you were using a tech stack that didn’t suit your team or purpose? Or because your own architecture was beating you up? What did you do? Did it help or are you still sad?

And there’s help!

If your project sucks, let’s talk about how to make it not suck! Starting with the Checklist Of Suck process!