Introducing Firestone, finally a framework for those who love reinventing the wheel. Firestone is a Universal Wheel Reinvention Framework (UWRF) and can be used to build ANY type of software. Yes, that’s right, ANY type! Web applications, desktop apps, mobile apps, frameworks and class libraries of any sort, and anything new that happens to come along in the future.

Sound too good to be true? Well just see what some of our early adopters are building with Firestone:

In-house Custom Source Control System - Who needs Git, Bazaar, or Subversion when you can just roll your own? Hell, Linus Torvalds did it, why shouldn’t you?
Custom O/RM Framework – Because your stakeholders are paying you to code not use something someone else already built.
Custom In-house Operating System – Why should your internal users be burdened with Mac OS X or Linux? Building and deploying your own Operating System allows you much more control over updates. Perfect for small businesses.

Download Firestone Now!

firestone.0.9.1.tar.gz

firestone.0.9.1.zip

Looking for documentation? Unfortunately, we don’t have any time to write any because we’re too busy reinventing those square wheels. Don’t let this hold you back, you know you wouldn’t have wrote any yourself, after all why should someone need to understand what you did when they can just reinvent another wheel?

FAQ

Is Firestone just for the arrogant and ignorant?

Unfortunately yes, our research has found that you must meet both of those qualifications in order to use Firestone effectively.

Where’s the documentation?

We don’t have any time to write any because we’re too busy reinventing those square wheels. Don’t let this hold you back, you know you wouldn’t have wrote any yourself, after all why should someone need to understand what you did when they can just reinvent another wheel?

What if I feel that I could do a much better job without Firestone and just write my own UWRF?

We understand completely, quit talking about it and do it!

Are you insane?

If you haven’t figure that out by now then Firestone isn’t going to help you.

Dirty Code Is Not Technical Debt

I do not believe authoring dirty code or code without corresponding tests should be considered technical debt at all, but I do sympathize in that the debt analogy still makes sense. However, this is not the type of debt one should ever want to take on in a project. There is never a valid reason for authoring dirty code or code without tests.

I consider this form of technical debt to be toxic technical debt. That is the debt analogy applies but the risk is not ever worth taking and eventually it can bankrupt your organization, quite literally.

REAL TECHNICAL DEBT CAN BE BENEFICIAL

I do agree that technical debt is perfectly acceptable to take on for valid business reasons as long as you pay that debt back responsibly, by making a large or complete payment on the principle starting in the very next iteration. Paying only the minimum balance will get you into big trouble, just like in real life.

A simple real world example would be if you had a software service that served multiple customers from a single installation. Let’s now say that you acquire a new customer and the first thing they want is to be able to run the application on their own domain with a slightly modified theme. The problem is that your app is in an early stage of evolution and doesn’t yet support such features, though you do want to get this customer up and running before you lose them to your competition.

As a team you might decide to take on some small technical debt in order to service your new customer faster. Instead of adding new features you could just create another instance of the application with a different configuration and slightly modified default theme. The key here is that you want do it with intention of building this feature into the main application and getting rid of the separate instance once you have the customer up and running. Not doing so would be considered paying only the interest on the debt, something you want to avoid at all costs.

Even though technical debt can be beneficial, the risk of taking it on should always be considered carefully.

Red flag #1 Fixed Bid

One might be thinking that a fixed bidding process is a great way to control costs on a software project.  This is exactly the nature of the fixed bid trap set by sleazy custom software companies, they lure you in thinking you’ll be getting your project delivered for less without worries of going over budget.  This is a fallacy, the only way to really control costs is to receive continuous delivery of valuable software.

The problem with fixed bidding is two fold.  On one end the temptation of the consulting company to under-estimate and under-bid is too great, and the temptation to then cut corners becomes too high.  The quality of your code and project will suffer, perhaps greatly.  The other problem is that these firms are very good at their core business (contract negotiation) they know how to write specification documents to be just vague enough that they can easily deem things to be change requests that most people would consider obvious.  At this point they now have you held hostage; you can back out and usually pay some retainer plus the cost of your project, or you can skip the change request and get less than what you wanted, but likely you’ll submit and pay more for the project than you originally thought.

A fixed bid project can only result in a few outcomes, in the first they compensate their under bidding with change requests and secondly they cut corners and drastically reduce quality to make the budget, but usually the result is a combination of the two. The reality is that in software you can only estimate small tasks with accuracy, estimating at the project level is always a roll of the dice.  Everyone’s understanding of the software requirements will change as the project progresses.  This is why true craftsmen would work with you in a customer-driven approach, delivering working software constantly so you can walk away whenever you feel you’ve achieved the value you wanted to obtain.

Red flag #2 Phony or Outdated Approaches and Methodologies

Their website might have talk of having methodologies but do they give concrete examples of them in action throughout their work?  More importantly, is the process or methodology they follow an accepted industry standard or do they just enjoy reinventing the wheel?  Perhaps they will reinvent the wheel when they go to implement your project. But more than likely it’s just fictional or simply high-level steps of their sales process.  Agile and customer-driven methods will be highly visible throughout the interactions with the reputable shop, these will be prevalent in the more competent and legitimate companies.

Red Flag #3 Outsourcing to Developing World Countries

In this case the shop becomes almost nothing more than just a middleman and you can almost guarantee they are using online freelance services.  This is not bad because developing world countries have worse programmers than here in the United States, quite the contrary.  Exceptional programmers are individuals that represent every nationality and ethnic background.  The problem is that these exceptional developing world programmers are not going to be the ones working on your project.  The ones who will be working your project will be of the lowest percentile in skills and ability.  This is because those exceptional programmers even in the developing world are going to have greater economic opportunity than working on a middleman’s outsourced project, in fact most of the highly skilled will have opportunities to work abroad in rich developed nations throughout the world.

One can almost guarantee that any work contracted out to a third party (regardless of destination country) will result in what is considered commodity programming, meaning that the code will be very poorly written and brittle and thus hard to maintain and sometimes almost impossible to extend or change without significant costs.  Yes, the quality of the code itself is of utmost importance, don’t let them try to tell you otherwise.  Unfortunately the sleaziest of custom software shops will avoid mentioning they perform these activities, in fact they might even flat out lie about it.  This is where you have to really do your homework and hit them with the hard questions, find out all you can about the size of their team and internal practices, a company that just farms out projects can’t hide every aspect of it.

Red Flag #4 Trumped-up Testimonials

Lots of testimonials and prior customers in a portfolio doesn’t necessarily insure that the company is not sleazy.  Beware of the shop that tries to sell itself based the reputations of it’s past customers, ask yourself why they are focusing on this so much when they should selling you on their expertise and abilities.  It’s amazing how some companies will greatly embellish, often using their friends who might work at a major corporation to write them a quick and positive testimonial.  Since anyone can simply ask one of their friends to write them a testimonial or a review, you should not even consider these testimonials when selecting the right company.

Red Flag #5 Lack of Quality Standards

A reputable shop should have a set of quality standards defined and they should be able to share these with you without any hesitation.  You want to make sure that they have standards for coding style, software design, and even content.  Their standards should also be right inline with industry standards of the related languages and technologies they plan to use. They should use test-driven development or at the very least write unit and functional tests concurrently with your project.  The result of your project should not only be the code but also the code the makes up the unit and functional tests, after all this is an important part of your software and you will need these for maintenance and implementing changes in the future.  There should even be some minimum Code Coverage metrics agreed on up front.

Conclusion

If you are shopping for custom software services please take this guide to heart, don’t let the charlatans try to convince you that any of the these red flags are acceptable practices.  Feel free to contact me or post any questions you might have about your experiences, I’d be more than happy to help you in selecting the right craftsmen for the job.

I’m attempting to strengthen a weakness in my knowledge, that weakness is working with legacy code or really being able to confidently change legacy code. Legacy code as Michael Feathers puts it in his book Working Effectively with Legacy Code, is simply code without corresponding tests. It doesn’t have anything to do with when the code was written or what obsolete language it was written in, legacy code is code without tests, often poorly implemented code without tests.

The concept of changing this kind of code with any level of confidence is something I’ve struggled with, in fact I’ve had to work on legacy code that was written this year, again proving that legacy code is not necessarily old code. As Feathers puts it, someone may be writing legacy code on your project right now. The amount of legacy code far out numbers the amount of new code.

You know you need unit and functional tests but the biggest problem is how to implement such tests on a system that wasn’t designed with that in mind in the first place. To introduce tests it seems you have to change code, sometimes lots of code, but if you don’t have tests already then how can you do that with any degree of confidence? I would say the current strategies I’ve learned over the years only cover about 20% of the cases, leaving about 80% to slow coding and repeated and mostly redundant manual testing and in the end a little of just hoping for the best outcome. Legacy code sucks, it drains the productivity out of you and cost the stakeholders money with slow development and and increased number of bugs with even the simplest changes.

I’ll let you know what I’ve learned in a full review I will write after finishing this book.

Here is the StyleCop settings file I use on my C# projects, this disables some of the rules I feel are overkill:

I would exercise caution when disabling rules, especially in a team situation where you are using this tool to enforce a standard style. Before disabling a rule you should consider what damage the lowest common denominator on your team could do without that rule in place. I also find this tool works hand-in-hand with FxCop, even though there is a little overlap in some areas.

I find it very useful to run StyleCop before I commit some code, often it will show me things I just simply overlooked because I was too focused at the task at hand. Of course this tool can only check the style of your code and while there are rules for naming, choice of meaningful names and sound software design is still left up to us humans. Remember to always leave code in a better condition than when you started working on it and use StyleCop to help you find things that can easily be addressed.

What I noticed on my previous Android device was that if I didn’t perform task management every few days, performance would suffer.  This is something I hear users complain about, even the girl who cuts my hair would tell me how her myTouch “just doesn’t work as well as it used to” or “is slower than it used to be”.  Most users simply won’t know they will need to perform task management on a weekly basis to keep their device running smooth.

Then I picked up a Nexus One in January just a few days after it had been released.  The difference was like night and day, a power user’s dream.  I could load as many widgets as a wanted and I would run many background services without ever needing to manage tasks.  The device simply has enough horse power to keep up with even a user like myself.

However, I do see a bottleneck on the horizon with my Nexus One: Internal Storage.  The internal flash storage on the N1 is 512MB, much better than previous devices and this was fine for my situation until recently.  I had accumulated a lot of apps, with some of them now containing quite a bit of user generated data.  Last week I was a little surprised when I received a notification telling me that internal storage was getting low.  I immediately went through my apps see which ones I could move to the SD Card via the new feature in Android 2.2 (Froyo), however many developers (including myself, which will be addressed soon I promise) have not yet released updates to allow this feature.  When that wasn’t enough I then I had to go through and remove apps that I could live without.  Followed by removing data from certain apps that I could also handle not having. That’s never a fun process to go through.  What really got me was that I had so much available space on my large SD Card, but I couldn’t utilize it fully.

In conclusion I think that the Android development team needs to make “preferExternal” the default install location setting and move the choice away from the developers and into the hands of the user so that any application and it’s data can be copied to the SD Card and installed there by default if space is available.  If the choice is still left up to developers then you can bet that internal storage space will be a factor in deciding my next Android phone purchase.

The Bad

From a developer perspective, AndroLib and AppStoreHQ are just outright annoying.  Not only do they not keep updated and accurate information about your apps, they are very slow to update them.  If you want your app listing on their site to be update-to-date you must register with them and request they update it when necessary.  The processes for requesting updates are kludges at best and incomplete, requiring a manual request (email) to update aspects of the listing such as icons and screenshots.  App Developers don’t have a lot of time to waste and having to keep emailing the owners of these sites to request updates and going through their kludgy processes is a waste of time, time that could be spent developing better applications.

From a consumer point of view, AndroLib is the worst of these two.  Usability on this site is horrible, it performs poorly, and just looks ugly.  Information seems cluttered on both AppStoreHQ and AndroLib again pointing to the usability issues of these sites.  It should also be noted that AppStoreHQ does not only index just Android apps but iPhone/iPad and plain old web applications as well.

Enter AppBrain

Now here is a site that nails it perfectly, not only do they automatically update all details of your app, they do so very regularly and without any intervention on your part.  This is how one of these sites should be done, not only from a developer perspective but also from the view of the end consumer.  The site is very minimalistic, performs well, and really has some great market integration features allowing you to sync your installed apps and install from their web site.  Not to mention the fact that they have an Android app and they have implemented techniques to filter out those many junk/spam apps that plague app markets.

Conclusion

If you are looking to build one of these sites I suggest you look at AppBrain as a model first.  If you are the developer of one of the other sites then I suggest looking at them as well, you might learn something.