programming - DevBurner

BaBSE 7: Perfect Planning Doesn’t Exist

August 24, 2012 by Chris Leave a Comment

I’ve been “working” on a web app for sometime now and will use it as my “calling card” moving forward. It’s just something small and effective that I need to create to ship something into the world, to break the ice, and to create a platform to build off of.

The problem is that I plan too much, too often, and when I get stuck planning the application, I freeze and don’t do anything. But, it doesn’t have to be that way for technologists and software developers.

Big systems

When I was working for a large insurance company we had some intense project planning going on. Timelines, small project packets (200 pages isn’t small though), meetings, meetings, and more meetings. It felt like overkill, but, in reality was probably an important thing to do for the complexity and depth of what was going on with different pieces of software, not to mention we had to make sure that regulatory and certain legalities were taken care of. Some of these systems were 20/30 years old and we were integrating new stuff with them which added another portion of complexity.

This type of in depth planning is mostly needed for large systems (although, some of the meetings were a complete waste of time). But, even those these plans that are in a perfect little Gant charts, created with picture perfect white board sessions, and detailed in small project packets with code and comments aren’t perfect and sometimes completely fail.

Small systems

With smaller systems and apps we have the choice to not go into as much detail when we plan. We can get away with skipping complete plans and timelines and concentrate on smaller, more concise plans that actually mean something. Here are two awesome resources for planning software:

Painless Function Specifications Series from Joel on Software
If you want to do a little more in depth planning, this is the way to do it.
Getting Real by 37signals
If you want a “no-BS” approach to making quality software without the overhead of planning too much, this is the way to do it.

Here’s the hit

If you are planning large or small systems you can’t do it perfectly (even with the awesome resources above). You can get close to creating accurate plans, but it’s never perfect. So, instead of spending the time to create a plan that is “iron-clad”, spend less time making a passable plan and then start creating. When you hit a brick-wall with your plan or things don’t match up with your plan then change your plan.

What tends to happen, at least with this technologist, is that I plan some software (mockups, requirements, small functional spec, etc.) and when my actions start to go outside of the plans, I start to think that my plans are “wrong” and then scrap them. That’s not how it should work. We have to remember as technologists and developers that plans will change, especially for small or medium size systems and even more so when you don’t have any sort of hard requirements (like legal or regulatory).

So, rather than plan for perfection and think that you have failed when plans change, plan for change and understand that your systems will never be perfect even after the system has shipped.

Filed Under: Development Tagged With: babse, development, getting real, programming, software, software development

Programming Isn’t Important Anymore

August 3, 2012 by Chris Leave a Comment

On the latest .NET Rocks! podcast (yeah, I’m a Windows user too!), the topic was about the “newish” Visual Studio tool Lightswitch. Lightswitch allows a user to quickly create a business application with a rich set of design tools. A user can create their own database schema as well as import data from existing databases. They can create screens, screen flow, and then push it out to end users. Basically, Lightswitch allows you to create a solution to a problem with very little code (often times no code at all).

“No, coding! Well, some developer you are. To be a developer you have to code.”

Well, not so much. I think that it is more important to solve problems quickly then it is to code.

Programming for the sake of programming

During my day job I work on Windows and do a lot of development work in C# using Visual Studio. I feel that the C# language, .NET, and Visual Studio are highly polished and help me be productive when it comes to creating applications. But there is something that can come up with the best frameworks and languages out there; too much code. Developers and engineers get into “solve this problem” mode and then come up with a solution that is highly engineered and as close to perfect as possible.

But, really, the customer or end user of the solution that these engineers are creating just want one simple thing; an answer to their problem. Something else that they want about 99% of the time is that answer to be here today. As a technologist, we need to deliver answers to problems, not code.

Enter abstraction

A few months ago I got really excited about the new FileMaker suite for Mac and Windows. You could quickly create highly polished and usable, multi-user applications for the desktop and then push them out to an iPhone or iPad. This was an eye opener for me. It showed me that I didn’t have to code something to solve a problem; that I could spend 80% of my time implementing a solution and the other 20% tweaking it and supporting it. That was huge.

The idea of abstracting out technical backend code and flow of an application to software that can handle it is nothing short of a miracle for technologists. It allows us to think technically and solve problems rather than battle with code and oddities of languages. It allows us to concentrate more on how to solve the problem than the technology itself which helps us get more done. It allows us to deliver a product and answer faster and more accurately. All of this makes happy end users and customers.

You don’t have to code

Just because you can program in C, doesn’t mean you have to. If you want to be able to get more done and solve real problems for people, then coding more isn’t your answer. Using technology tools that enable you to solve problems faster is.

Now, don’t get me wrong, coding is great and I love to do it. But, as technologists we should never be reinventing the wheel. We should know how the wheel works and how to use it. Then we can use it to create and solve something else. So, rather than spin your wheels on a problem that has already been solved, use technology to solve something new.

Filed Under: Technology Tagged With: .net, c#, coding, filemaker, lightswitch, programming, technologist, technology

It Ain’t Easy Being a Creator in the Post-PC Era

March 8, 2012 by Chris Leave a Comment

In case you missed it, a company from sunny Cupertino, CA announced a new product yesterday. The new iPad is said to amaze us and push consumers further into the post-PC era.

The post-PC era sounds all fine and good for the consumers out there sucking up content, replying to emails, and looking at photos, but what about creators? Are they left out of the post-PC era, or can they (we) too use post-PC devices and ideas to create content, products, and things that change our world?

For the creators

I remember when the first iPad came out. Many tech pundits and media said that the device what a “consumption-only” device because of its lack of a physical keyboard, camera, etc. No one could really create anything on this thing. Then we saw

Creators need tools that can react to input and changes immediately[1. Thanks to Mr. Schechter for the link], showing them what they are in the process of creating. Creators need tools that are ubiquitous and easy to use. To think that someone can’t possibly create something because they aren’t “doing it the hard way” is starting to be an annoying remnant of curmudgeons that are showing that they are afraid of the future.

The new tools like iPhoto, iMovie, and the iWorks suite show us that we can use thin, light, and “limited” devices to create. We are slowly seeing that we won’t need bloated devices, 8GB of RAM, and spec crazy devices to create with.

The fact is that creators want tools they don’t have to think about and that get the job done. If it is in the form of dictating to an iPad, using a Bluetooth 4.0 pressure-sensitive stylus, or just a plain old wireless keyboard then that is awesome. If technology is reducing the friction of creation by giving us easier and more beautiful tools to use, then that is the new way to create.

What about programmers and technologists?

Programming on the iPad (or any tablet/post-PC device) is a bit of a bear and something that hasn’t been fully paid attention to yet. Other than remotely connecting to another PC, Mac, or Linux box and using your device as a dumb terminal, there isn’t really any way to compile and create software directly on the device. Other than programming, tasks like creating documentation, project plans, flow charts, business proposals, etc. But this is mostly “administration” type of work, not technological creation.

As of now, technologists and programmers are still tied to their Macs and PCs until there is a good way to incorporate all of their powerful tools on a post-PC era type of device. Sure, we can use remote facilities of our devices to program, compile, and even push code out for consumers to use, but there is not yet a way to do all of this natively.

In due time.

Being a creator now

It’s not easy to be a full-time, post-PC era creator. But neither is being a creator, developer, or technologist in general.

This is a new time and place and we are still feeling it out. It’s still the early days and as of now, it appears much easier to be a consumer. The tools will definitely get better as we the creators demand them and create them for each other. So, don’t give up your MacBooks and PCs just yet; the post-PC era isn’t fully realized for technological creation.

Filed Under: Technology Tagged With: creation, creativity, development, macbook, pc, post-pc, programming

Ubiquity is a Feature

February 20, 2012 by Chris Leave a Comment

Are you a Mac fanboy? A Windows “Power User”? Do you scoff at how “zealots” tote around their iThings and disregard anything and everything else as being a viable option? If so and you are a developer or creator of software, you may want to take a step back and consider including the “ubiquity feature” in your apps.

Cross platform app development is here to stay. So, rather than disregard it, use it as a feature of your software.

Other OSes exist

I have had quite the transition from Windows user, to Linux user, to Windows “power user”, to Mac, to anything under the sun user. What I still find hard to believe is that some developers only offer their software for certain “platforms”, even with the availability and growing power of creating a web and mobile applications. The fact is that there are other OSes in the world.

Many Mac aficionado tend to think that there are only Macs in this world. As Apple has been making a killing lately with iOS and even with OS X, we have to remember that the majority of people on earth run Windows. This of course will probably change as Microsoft has been digging their own grave for well over ten years now because of their stagnation, but the fact remains that there are many OSes and platforms out there to support.

We should plan for them

There may be a number of good reasons why developers create software for a certain platform or another, but if they are creating frontward facing services for end-users, it seems like a real misstep for them to not use web and HTML 5 technologies to make their apps available to all.

Developers (especially fledgling ones like myself) should plan for this. Rather than develop apps for a certain platform, we should be opening them up to anyone and everyone. We are limiting ourselves because of lack of experience in a platform or just plain “zealotness”. At the very least, developers should offer robust APIs so that other developers that have an interest in a certain platform can interface with their software.

Cases and points

One good example of a software company that is doing this right (other than the whole not charging anything part) is 6Wunderkinder. They used Appcelerator’s Titanium products to make Wunderlist available online, for Mac, Windows, Android, and iOS in record time. And for the most part, everything works without a hitch. We can argue whether Wunderlist has the features that one needs for tracking their todos, but what we can all agree on is that in this case Wunderkinder has made ubiquity a feature.

Twitter is a great example of an app and service that made a great API for developers. This can be argued to be one of the main reasons that popularity for Twitter grew so quickly.

Another good example of this is the webapp Toodledo. It may not be the most grand, exciting, or pretty app, but Jake at Toodledo has done a hell of a job of making his app ubiquitous as well as created a great API so third party developers can create applications that work with it. Yet another is the new app Asana (one that a good friend has adopted over an app that can’t be used cross platform) which has a very responsive web interface. The mobile app is sort of lacking, but new additions are made consistently.

Other apps like OmniFocus (or anything from the OmniGroup), Microsoft Office (although it’s getting better) and others are limiting themselves by not giving users the ubiquity feature or decent APIs for third party developers. These developers may scoff and say things like, “well, you can’t get real work done on a Mac anyways (yeah, that’s you M$),” or “we want to only cater to the Mac platform,” but the fact is that the OS is becoming less and less important with the availability of the web and the growth in the power of web and mobile technologies.

Conclusion

I can’t say that apps that are only for iOS or Mac or Windows won’t do well (because apps that are only for those platforms continue to do well). What I can say is that ubiquity is a feature, that cross platform app development is important, and should be added to any new application that is being released. Whether the apps are ported to a specific platforms, available on the web, or have an API that other developers can access, developers need to pay attention and make their apps accessible from anywhere at anytime.

Filed Under: Development Tagged With: apps, development, programming, ubiquity

A Toolset for a Productive New Year (2012 Edition)

January 2, 2012 by Chris 3 Comments

As we enter 2012, it’s a good time to take stock in the tools that you will be using to get things done this year. I’ve learned a lot about my workflow this year. I’ve also killed a lot of productivity tools that I have wanted to work in my life but just couldn’t get them to. Here is how I’m putting my systems in check, especially as I start a new position with a different company and continue my onslaught of the productivity space with Mr. Vardy.

Going paperless

I’m making a concerted effort this year to get as much paper out of my life as possible (you know, except for my luxerious Moleskines). Really, I just want to get rid of my filing cabinet and get rid of paper billing as much as possible.

The tools to do it?

ScanSnap S1300 portable, duplex scanner
JotNot Pro
Evernote Premium
PDFpenPro
Time to convert all my billings to paperless

Productivity tools and systems

I tried and failed this year to find a tool that was cross-platform (iOS, Mac, Windows, possibly Web) that stood up to OmniFocus. There is no such tool. Seriously, stop looking. So, I basically bit the bullet and started using OmniFocus more on my iPad and treating anytime I used Windows as a context. This helped out a lot. I’ve got a long list of tools for this section, but they all play a vital part.

OmniFocus for Mac, iPhone, and iPad. My GTD, project planning, life managing, mega-tool.
Evernote. Good for keeping track of things other than long form writing.
iThoughts HD. The best for mindmapping and starting off my project planning on iPad.
MindNode Pro. The most valuable mindmapping app for Mac.
Fantastical. I love how you can enter new appointments with natural language. It’s also great because I don’t have a super complex calendar (yet).
Google Calendar
Microsoft Office. It’s the best on Windows and not too shabby on Mac. I only use it for the heavy lifting though.
Moleskine Cahier. Can’t be paperless all the time.
Livescribe Pen system. Great for meetings and making sure I don’t notes that I took on paper.

Development tools

I’m a developer and soon to be IT Manager. I have to make sure that I have tools that fit my needs and help me be productive while programming for Windows and web.

Visual Studio. You want to program on Windows? Okay, you will need this.
ReSharper for Visual Studio. The greatest add-on for Visual Studio ever created. It’s not expensive either for what it can do. I think I would forget out to write LINQ without it.
NSpec. Good for the Business Driven Development that I am learning. I first started BDD with RSpec for Ruby on Rails. I like it so much it’s made its way into my .NET life.
soapUI. The best and free way to test web services.
Notepad++ for Windows. No comment.
BBEdit for Mac. Once again, no comment.
EMEditor for Windows. The only way to open a 1GB text file that I know of.
Ruby on Rails. Web programming “The Rails Way” is the way that I will be doing so moving forward. I didn’t have the opportunity to use RoR at Erie Insurance as they don’t support it, but with my new gig, anything that will need thrown on the intranet will be done with Rails.
BeyondCompare for Windows. A great tool for comparing files.

Writing tools

I plan on writing much more in 2012. Not only will I continue my 750 word a day habit of personal rambling, but I plan on developing this site as well as writing a book or two. I prefer tools that don’t have too many bells and whistles and stay out of my way.

BBEdit. Again? BBEdit could possibly be the best 50 bucks I have ever spent.
Byword. This is still buggy for my on the Mac, but I do like the fit and finish of it. Great for using Markdown.
Marked. Mr. Terpstra knows what the hell he is doing and has made my use of BBEdit for writing with Markdown perfect.
WriteMonkey. Hopefully I won’t be writing as much on Windows, but when I do it will be with WriteMonkey.
Notesy and Nebulous Notes for iOS. I love writing on my iPhone. These are the tools I do it with.
Dragon Naturally Speaking. I use Dragon Recorder on my iPhone and then transfer it to Naturally Speaking on my Windows virtual machine. Why do this? Because Naturally Speaking was on sale for about a third of the price as the Mac version and has about 3 times as many features as the Mac’s.

That’s it

This is my nice minimal setup. By the way, Dropbox should be included as the glue that holds my digital world together. It isn’t listed here because nothing on earth works without it anyways, right?

Every tool here is used and has a purpous. I’m not going to try to minify my tools to just be minimal. I will use the tools that make the most sense, work the best, and provide me with the most value. These are those tools. Hopefully with my toolset and some elbow grease, 2012 will prove to be a productive and great year.

Filed Under: Productivity Tagged With: development, paperless, productivity, programming, tools

Becoming a Better Software Engineer 2: On Learning Language(s)

October 31, 2011 by Chris 1 Comment

“What programming language should I learn?”

Ahh… the common tome that I have heard and said myself through the several years gearing up to be a software engineer. I’ve come to realize that the reason why new devs ask this question so often is that believe the language they choose will make or break their career. This is sort of true, but more of a fallacy than not.

First about me

The first thing I learned when I was young was some HTML and CSS so I could create websites. I remember starting a Star Wars website when I was 12 or 13. It had a Galaxy background and everything. I wouldn’t necessarily call HTML or CSS “programming languages” (‘markup’ fits), but it did introduce me to the idea that there were syntaxes that you could use to manipulate data and the presentation of it in some way.

I didn’t really start programming until I messed around with PHP around the age of 18. I wrote a few custom things like sign-up forms and learned how to pull data out of a MySQL database, but that was the extent of it.

I really started programming when I entered college and learned VB, C# (both with .NET), C++, bash scripting, Java, JavaScript, and XML. This is when I actually wrote programs that compiled down and could be run on a computer. So, I would say that I have been programming “for real” for about 4 years.

Now about you

So, what language(s) should you learn? As many as you want.

I know, I know. Not the answer you were looking for, but it’s true. Learning programming languages to a developer is like learning spoken languages to a world traveler. There is a “core set” that you need to know to get things done now, but there are so many more interesting ones that you can use later in your travels.

So, here is a basic plan that can probably work for just about anyone.

1. Learn some “standard languages” first

First, learn at least one, if not a few, “standard languages”. By this I mean languages like C, C++, Java, or C#. All of these accept for C# are cross-platform and are (at the time of this writing) in super high demand. You really can’t go wrong with learning any or all of these languages. Plus there is a ton of information about all of them on the web.

2. Learn a “web” language

Since the web is the new cross-platform platform, you should invest some serious time in learning a web language or two as well as some frameworks. If you don’t know HTML or CSS you better get on those. After that you can learn some web languages like PHP, Ruby (for Ruby on Rails), C# and .NET libraries, Java and web libraries, etc. These are by no means all the “web” languages that are available to learn, but once again, if you learn these few you will definitely be applying yourself in areas that are marketable.

And of course you should learn JavaScript as well as a good JavaScript wrapper like jQuery.

3. Dive in

After you have garnered a nice set of “standard languages” under you belt, it’s time to dive into anything and everything you little hacker heart desires. Learn Scala. Grok F#. Write some Perl then try to understand it after you write it. Get into any language that you think is cool and then get passionate about them. There will always be new and “better” languages that enter the development scene. You will never get bored as a developer, nor will you ever learn and know everything.

Wrap-up

You may be thinking,

“I wanted to know exactly which programming languages to learn to be a relevant developer. Thanks for nothing”

Well, if you are looking for a “magic-bullet” type of programming language to be the absolute best for your first language to learn, then stop it. It doesn’t exist. There are definitely some great languages to learn off-the-bat that get you started programming, but the reality of developing software for an extended period of time is that you will have to learn several languages and keep learning them throughout your career.