My blog has moved to http://blog.derekbobo.com

I moved my blog. Visit http://blog.derekbobo.com for the new one!

Archive for January, 2009

Judging character

Posted by derekbobo on January 23, 2009

I heard something I thought was interesting today so I thought I’d share. I was talking with a friend who mentioned a way to quickly assess someone and come up with a pretty accurate opinion and that is to use F-O-R-M.

You basically ask a few simple questions about:

F – Family
O – Their occupation
R – Their recreational activities/interests
M- Money

Obviously how you phrase these questions is important and they can’t be rapid fire, but I certainly found it interesting. I think most of us have probably used this technique at least inadvertently. I think it’s definitely a way to feel a person out.

I’m going to keep an eye out and see if I do this as I encounter new people. On the flip side I’m going to try and be conscious of it when I meet others.

Advertisements

Posted in Business | Tagged: , , | Leave a Comment »

Packaged Software vs Custom Develop

Posted by derekbobo on January 23, 2009

In all of the organizations I’ve worked for or with I seem to always end up analyzing this long standing question. Should the client buy packaged software or build their own? Most people think that they need to buy the software. They say that they get higher quality and support. They also say things like they’re better off because they can easily find people who work in these environments.

I’m just not sure I agree. The are absolutely situations that it makes sense to use packaged software, but I think people need to realize that many of the reasons they say they are buying software are based on false assumptions. At the company I work for we are in a situation right now where we are having trouble getting our ERP software vendor to show up. The system needs a lot of love, and were almost 2 months past when the consultants were supposed to be on site. How’s that for support? Unfortunately since it is canned software the internal development team cannot touch it and we’re held ransom until they feel like showing up. I won’t even begin to try and figure out the cost associated with initial purchase, implementation, custom features, and ongoing support, but I’d wager it is significant to say the least.

The other thing I seem to see every single time is a piece of packaged software that has been bastardized beyond the point of return. When you buy one of these big software packages you buy a way of doing business. Unless you are willing to make that commitment and stick to the tools way of doing things; I must say you are in for heart ache. The “fixes” or “workarounds” that you come up with to make things work end up causing you a lot of pain downstream. Upgrades or migrations to new systems become next to impossible. Tasks that should otherwise be easy to implement seem to become more and more complicated and users (or customers) start to get frustrated. When this happens you quickly move towards a system that will have trouble scaling and adapting with your business.

The other thing I find amusing is that you pay hundreds of thousands (or millions) of dollars for these bloated systems. The thing is they are trying to be everything to everybody. As a result you pay for all of the available “features” but you only use a small portion of them. Aside from the fact that you’re wasting system resources, you’re also creating a larger environment than you really need. This makes it harder for you to track down issues that pop up. That doesn’t even begin to touch on the fact that you are working with a magic box. You throw some data into the black box and some data comes out the back. If what comes out isn’t what you expected you’re at the mercy of your vendor to help. That’s right they’re saying cha-ching cha-ching cha-ching as they stare at you with $$$ in their eyes.

My final rant is one of integration. Despite what the sales folks tell you, there is not a silver bullet/one tool that solves all your problems. You will undoubtedly try to bolt new systems onto whatever drives the core of your business. Once again the ability to pull this off creates a big dependency on the vendor (cha-ching, cha-ching….). You end up jumping through all sorts of hoops to pull off integration which exposes your system to more complexity and makes change very difficult.

On the custom development side of things folks become afraid. They don’t like the risk associated with putting a dependency on internal resources, they believe that the tool is harder to maintain, won’t support future enhancements, etc. These are absolutely things to be concerned with, but most of them also exist with packaged software.

Ultimately, I guess my thought is packaged software makes perfect sense for commonly used tools, such as email, word processing, file sharing, etc. Items which have become standard in most of today’s businesses. If you can commit to the software’s way of doing business, then go for it. You’ll probably have a quicker time to market, otherwise save yourself the headache because your setting yourself up for potential disaster.

If you see the light you simply need to manage custom builds appropriately. Have multiple people engaged in the development. For big projects this may mean multiple consulting firms, and/or the use of internal personnel. Then you just need to share knowledge and document. If you do this your software will be every bit as good as the packaged software you could by and most likely at a lower cost of ownership. You will have a leaner system that does business the way you want, and you will have direct access to modify it as you see fit. Because of these things I would argue that in many cases you’re going to have a more scalable and flexible system than you would with packaged software. If you do this you’re not committed to any particular vendor and you’ll be able to fit the tool to your business rather than your business to the tool.

Posted in Business | Tagged: , , | Leave a Comment »

Just an update

Posted by derekbobo on January 21, 2009

Things have been going a lot slower than I’d care for lately. I’ve had a number of busy days at work, we adopted a new puppy, etc. “real life” has just been keeping my on my toes. That aside, I’ve tried to dedicate at least a little time each day to being productive. My hope is that if I set small goals I’ll continue to work on things without getting overwhelmed and before long I will have probably done far more than my goals for that night.

I recently jumped into building some of the core system stuff. By that I mean all of the business logic and data structures that will allow this beast to chug along without a lot of babysitting on my part. I had actually intended to work on the back end of the product itself, but pretty quickly realized I hadn’t built out containers for most of that data. I ultimately ended up on somewhat of a different path, but it was all still productive stuff and proved to be a nice change of scenery.

So over the last week here are some of the things I’ve been working on:

  • Design core system database. This includes features for invoicing, payment processing, accounting, CRM, etc
  • Since something like 75% of development time is spent validating user input (stupid users!) I worked on some libraries that handle input validation. I can now write forms assuming that the data is valid and then pretty easily drop in the rules after the fact. These utilities also handle maintaining page state and displaying any error messages.
  • I also added a utility for handling hashes and encryption. This will be useful when it comes time to securing sensitive data (and even user/password type stuff).
  • Building out some of the administrative forms that allow me to create clients, associate people to that client, etc. Basically I want to get enough of the core features built out that will allow me to create any components that will be required for the actual product rollout. Extra bells and whistles I can implement as needed.
  • I started noticing my code getting cluttered with some manual includes, so I rewrote my autoload function to include recursive autoloading of classes. This is definitely a handy feature.

I don’t feel like I’ve accomplished much over the last week, but when I write it all out (above) I feel a little better about it. I’m just going to keep chiseling away at it. I really don’t think I’m too far off from where I need to be, but I had to build out some of this foundational stuff in order to save myself time downstream. In hindsight I guess I was more productive than I originally gave myself credit for, but I guess the perception is that you accomplished more when you have something you can actually see.

Posted in Business | Tagged: , , | Leave a Comment »

Ready… Set… GO!

Posted by derekbobo on January 12, 2009

I’ve built a lot of stuff in my day and I’ve worn a lot of hats. Having said that it’s nice to be calling the shots and planning things for myself. I sometimes get frustrated in my “real jobs” when I have a great idea/approach that will positively impact the business. Instead of being able to fucus on just getting it done, I have to sell the idea. Weeks or months later… when everyone has had a chance to get their say in, I’m exhausted and not nearly as motivated to knock it out of the park now that they finally agree it’s a good idea. Sorry for the little rant.

With my current project I decided to skip a lot of the crap and just jump in and start building. My framework was designed to be pretty flexible so I pretty much hit the ground running. I mean, I’ve been thinking about this for quite some time so I already had a pretty good idea of the feature set I wanted. I created a project in my PM tool so that I could dump any random thoughts, created a few high level tasks and took off.

I’m only a couple weeks in and I have a functioning framework and I’ve programmed all of the core front-end functionality. I’ve also already identified a couple of features to implement for phase 2. I’m pretty pleased so far.

That was the easy part though. Now I have to build the administrative and management functionality. There is a lot more business logic and  thought that has to go into this piece. After all it needs to be as intuitive and automated as possible. I’m hoping by end of next weekend to be pretty far down the path… maybe not completely finished, but hopefully pretty close.

Once I get to that point I start to enter into a little bit of foreign territory. I’ve got to put together a game plan for selling this bad boy.

Posted in Business | Tagged: , | Leave a Comment »

The Framework

Posted by derekbobo on January 8, 2009

Just like any house must have a solid foundation, a good piece of software needs to have its base or framework thought out. As I mentioned before, my goal is to create an easy to maintain and scalable solution so that I can focus on value-added activities such as sales, new feature development, etc. Without a solid design I’ll get bogged down with tweaking the product rather than enhancing. That model just doesn’t scale. Period.

The other factor I’m trying to address is usability. Due to the market segment I’m approaching, I think it’s increasingly important to have a very intuitive interface. Similarly I’m trying to keep my feature set compact and focus on the big issues. My thoughts are very similar to Getting Real. If I keep my feature set compact focusing on the big issues I’ll be able to more quickly adapt and expand with my clients. If I try to implement every feature under the sun, not only will I have difficulty delivering the product to begin with, I’ll have more trouble evolving later.

My approach is a fairly classic example. I’ve built the framework implementing the M-V-C design pattern. This concept attempts to separate presentation (V-View), from business logic (C-Controller), from data access/manipulation (M-Model). There are a lot of debates over how to implement this, but in my mind, if you’re separating out these components, then you’re implementing MVC. Furthermore, I believe in writing code that just makes sense. Certainly there are some best practices to follow, but what sounds great in theory often falls short in practice. I guess what I’m saying is that I’m not a purist in that sense. In my mind it’s okay to have a little bit of logic in a view or model, but the majority of the logic should exist within the controller. It controls the application, ya know? That being said the only logic that is acceptable in a view is logic that relates to presentation – NOT BUSINESS LOGIC. Similarly logic can exist in a model if it relates to generating or manipulating data – NOT BUSINESS LOGIC. There are a lot of different opinions on this, but hey it’s my application so I’m going to do it my way.

I’m leveraging PHP, MySQL, and Apache for this particular implementation, but the concepts work for other environments as well. Interestingly enough I’m helping address a very similar problem at my “real job.”

The first thing to understand is the concept of SEO friendly URLs and URL rewriting. There’s a real slick way to handle this in Apache using the mod_rewrite module. Essentially what happens is a user types in a URL such as: http://www.somedomain.com/client/controller/action/param1/param2 – that’s the basic format. Now of course a URL wont always look like this, we can assume some defaults, etc, but I’m only going to use this example as it is easier to explain.

  1. So this URL gets entered into a browser and the user hits ‘Go.’ The request is first looked at by Apache’s .htaccess file. This file will basically take the request and forward it on to the index.php page. This page invokes some classes to parse the URL into individual tokens so that we can make sense of the request.
  2. The request then uses the tokens to determine appropriate action to take. The request is handled via a Router which uses the controller parameter to invoke the appropriate class. The action parameter is essentially a subset of the controller. It’s an event (action) that does some work for the controller.
  3. The typical case is that a controller/action will use the client parameter to load in the appropriate look-n-feel (master view). It also loads a sub view which is usually the template for a particular page.
  4. As was mentioned earlier the view does not contain any business logic. It should basically just define placeholders which need populated. This is where business logic and the use of models come in to place.
  5. A model is invoked to determine the appropriate data to populate the view with. We basically pass in any parameters to get some data back and then we use that data to populate the view.
  6. At this point our page is populated, rendered, and ultimately returned to the clients browser.

Now that I’ve completed an explanation, here’s the shorter version:

User Request -> URL Rewrite -> index.php -> Router -> Controller -> Action -> View/Model -> Return to user

It sounds like there is a lot going on, but the majority of it is transparent. This approach separates out the main parts of the code so that they are logically grouped and much easier to maintain. Furthermore, since the framework handles most of this behind the scenes it actually takes very little code to create new pages/implement new features. The whole concept is really pretty elegant if you ask me!

I’m pretty excited because my framework can be shared in some of the additional markets/products I intend to pursue in the near future. This means even less code to maintain, thus a much more scalable/maintainable model.

So that’s kind of where I sit today. The framework is in place and the dummy functionality is ready to go. Now I need to start working through my front-end user features one by one and then ultimatelly built the administrative tools that will complete the product. It’s all pretty simple stuff, but it can be pretty slow due to all the other stuff going on in life. I just gotta keep chipping away at it.

Posted in Business | Tagged: , , | Leave a Comment »