Category: Getting Started

The techniques and recipes set out in this blog are meant to be adapted to your own process. You could choose to follow them exactly and you would achieve great results, but I ultimately don’t think that is practical or sustainable. Why? You don’t live or work in a vacuum, and because of that you will need to follow this process when adopting these techniques and recipes:

• Practice the technique.
• Evaluate the process.
• Modify the process.
• Rinse and repeat.

The cornerstone of effective change is the process of engaging and adapting. Engagement comes from repetition and I call that working your process. If you engage and then adapt, you will find what works best for you and your business. A single test run will bring better results, but the actual gold is to repeat the techniques again and again and glean what works.

Mileage may vary

It is ok if these techniques don’t seem to apply to you. Not everything is useful to everyone. I’ve made a very successful career out of constantly expanding my toolbox and using the right tool at the right time. I’ve gotten proficient in adapting other people’s tools for my own use and this collection of adaptations are what I think will have value for your process. I would be doing you a disservice if I didn’t encourage you to work the exact same process to adapt these techniques to your specific circumstances. When I adapt and then adopt something, I have the advantage of experience to tell me what to change to fit how I want and need to work. Hopefully all of these techniques are bite sized enough to make then easy to wrap you head around, use quickly, and see effective results. 

Adapt, Adopt and Ignore

Use what you need to move forward, ignore the rest. It is ok to leave good ideas behind. Maybe they weren’t for you at this time and place. Don’t hold onto things that seem really great but simply don’t work for you. Don’t beat yourself up, it is ok. The important thing is to begin the process of adopting and adapting in order to get your project completed.

Evaluation is key

If a technique doesn’t work for you or doesn’t produce the results you want, try to figure why it didn’t work before modifying it. Did the breakdown occur because of sloppy implementation or is it just not right for how you operate the business? Finding out that why and pinpointing the failure points is hard. How do you reliably figure out what really went wrong? Never fear, there is a technique for that. Next up, we are going to get familiar with the 5 whys.

You may have never heard of a software architect, that is ok, no one in our industry can decide on any job titles. What is the difference between a Coder, Programmer, Software Engineer, Software Developer, Front End Developer, Web Developer or Full Stack Developer? Depending on the position requirements and company culture all of these job titles might have the same job duties but be labeled differently at different companies.

Same with Software Architects.

Wikipedia defines a Software Architect as:

A software architect is a software expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.

~Wikipedia

They use the term as a broad umbrella and define different types of IT or Software Architects within the same article: enterprise architect, application architect, solution architect, system architect, cloud architect.

Unfortunately most of the difference in the job titles and what these positions actually do ARE ONLY OF A CONCERN FOR PEOPLE IN THE INDUSTRY.

In other words, jargon for people who care about jargon. Just another way to exclude others from understanding your field.

Why Should We Care?

We shouldn’t care about the labels, we should care about what the role ideally does within your team (even if it is a team of one, it is still a hat you wear when creating a software project).

The problem is that most decision makers within small enterprise still think of software teams as being comprised of four roles: designer, developer, project manager and systems administrator. Oftentimes the “Team” is one person and they wear all these hats. Just because you have fewer resources, doesn’t mean the roles magically go away.

Understanding how the smaller the team is, the more roles each individual must take on is key to avoiding a major project pitfall: decisions by inaction. This concept is really a longer topic for another time. Back to the why…

I want to change the way you think about who is creating your software.

If you even think about your project team as having more than one role you are probably still missing what I consider a key component and concept of software development: the Software Architect. When this concept is clear to you, you will be able to make better, clearer decisions; without understanding it you are spinning your wheels and might not even know it until too late.

Why is this so important?

Your Software Architect role is the role that provides the project road map to the rest of the roles on your team. They make sure the project goals are front and center and decide on the standards and rules of how to implement the project. All the other roles need to be taking their ques from the architect.

Without this concept clearly defined, the team plays the “who is driving the bus?” game. Sometimes the developer makes the key decisions, sometimes the project manager or designer or sysadmin do, but none of them are using the same playbook or necessarily where they are ultimately going. Not knowing how they are getting from point A (start of the project) to point B (successful delivery of the project) creates underlying tension and manifests itself as extra time and overhead.

This is why I want to train you to think like the architect: to create the map to guide your team to successfully create the software you need. By following the recipes and techniques I’m going to outline, you will start thinking this way and when you implement like an architect your projects will become less expensive and easier to understand and complete. Saving you time, money and emotional dollars.

Welcome to the SME software cookbook. I’m glad you found me and I have a lot to share with you. I want to dramatically change the way you think about and create software for your business. I am going to create a cookbook of techniques and recipes to teach SME (Small & Medium Enterprise) business how to successfully create software.

Who is this for?

The cookbook is for non-developers, small business owners, IT managers, anyone who needs to build a small piece of custom software to help their business grow and feels like they can’t do it because:

• They aren’t technically minded and don’t have anyone on staff that knows how to make a software project happen.
• They feel like the software creation process is a big black box that you throw money into and nothing comes out but endless screaming.
• They have had a big, bad, no good, HORRIBLE experience with a developer(s) or software company in the past.
• They don’t want to be a developer. There is too much to learn.
• It is too risky and scary, like moving through fog at night with no idea where you are and your phone is at 1%.

If that is you, you are in luck

I don’t want to train you as a developer. I don’t want to train you as a project manager. I want to train you (or even better, someone who reports to you) to be someone who can easily put together a small software project, hire a developer, meet your milestones, CRUSH your deliverables and make everyone wildly happy. In other words, I want to train you to think like a software architect, no degree required.

It isn’t that hard.

You have got to be kidding me?

Nope. Really. It isn’t that hard. We definitely MAKE it that hard for ourselves because of a lack of organized thinking and a software industry that makes software for developers, by developers.

If we organize ourselves and change how we think of the software project as a task, we can get our software built.

I should know, that is what I do.

I’ve been a developer, technical project manager and above all a software architect for over 15 years. I’m built applications for small business and large enterprises.

I have learned over the years that most business owners have been taught ideas about software and information technology that do not serve them and make them avoid innovation as something that is too expensive and out of reach.

It is time to change all that and find a better way.

Come along for the ride…

Over the next six months I’m hoping to change the way you think about building software so you can more easily innovate, automate and effect change for the better within your business, without breaking your budget.