Respond to Change or else

Change is not magic.

Software development is a weird stew of activities.  It is a creative activity taking the vague guidelines of others and turning it into working code.  It is an engineering activity because it requires a certain mindset only found in engineering.  It requires business acumen because software should do something which supports business.  Finally, a software developer has to adjust to change because technology, business, and the world are moving at the speed of the internet.  It is my firm belief that the best software developers and Scrum Masters need to acknowledge this change and learn to work with it.

I am coming up on twenty years in the software business, and the skills I needed at the beginning of my career do not match the ones I use today.  Some principles do translate like HTML, CSS, and object-oriented programming but in the beginning, there was no such thing as generics, responsive web design, or C#.  I relearned the skills I needed in my career every 18 months.  The reward for this struggle is employment and opportunities to share my experiences with others.  I want to make sure that no one suffers the kind of failure or mishaps I have in my career.

The constant theme in my career has been responding to change.  When VB.net careers began to dry up, I learned to code in C#.  As screens became smaller and mobile computing began to grow; I had to learn Bootstrap CSS and Jquery Mobile.  I was an early adopter of Agile and Scrum, but that has not stopped me from reaching out to find out more frameworks like LESS and SAFe to be successful.  In this business, a person needs to keep learning and growing.

In the agile manifesto, this idea is called, “Responding to change over following a plan.” In our contemporary economy, there are no promises in business so as a working person it is important to make sure your skills are up to date and marketable.  As an employer, it is important to address technical debt and make sure your staff is learning the latest skills to keep your company infrastructure up to date.  Upgrade your servers, use an office suite in the current decade, and shun mediocrity in all its forms.

The only thing sure in the business community is change and to be a successful software developer or scrum master you must learn to embrace change.

Until next time.

When the Emperor has New Clothes.

Being an agilest is like this cartoon from
the Harvard Business Review.

This is a strange time. I live near the city of Chicago so the weather in March alternates between snow, freezing rain, bright sunshine, and temperature shifts of forty degrees or more.  In this environment of uncertainty, it made me think about agile development as I understand it.  I have been doing agile as a developer and a scrum master now for six years and I have discovered a few things along the way.

As a developer, I have discovered that upper management “loves” agile and scrum.  They like seeing work turned around quickly in smaller increments with a strong commitment to quality and helping the customer.  I have also discovered that agile makes senior leadership very uncomfortable because it exposes personal and organizational weaknesses which they may not want addressed for selfish reason.  I liken this to the short story from Hans Christian Andersen “The Emperor’s New Clothes.”  I have been laid off for pointing out the nudity of an organization and it stings.

I also understand that being an agilest person in an organization can be pretty lonely.  I spent months and years explaining to a vice president who used to work for a major consulting company that all we need are user stories and interaction from the business to start building software.  I will never get over his constant look of disbelief as he saw me push code to test and then re-factor.  He also couldn't understand why I hated technical debt so much.  If wasn't broke so he didn't want to fix it.  When you explain and provide evidence why what you are doing things has merit you will often receive the blank stare accompanied by “…that is not how I learned to manage projects.”

Finally, as a developer I learned I was never good enough.  Object Oriented Development and Web Forms with ASP.NET becomes SOLID development and using Model View Controller approaches.  Coding for ten years without having to write a unit test becomes learning how to write unit tests and learning how to use fakes.  I am always learning and relearning how to do my job so that I can do it better.  In some respects, I am like a doctor or dentist learning how to improve my skills and help others.

Becoming a Scrum Master was also a new experience.  I had to confront my beginner’s enthusiasm with the realities of working with people who had no enthusiasm.  I also understood it was one thing to understand the Scrum process it was another to put it into practice every day.  The members of your team are always watching and making sure that you are living the agile principles and practicing the values of agile; courage, respect, openness, commitment, and focus.

I also discovered that some people in an organization will never understand agile.  These people have a vested interest in having things work the “old way” and no amount of increase productivity or profits will change their minds.  I have learned to isolate these people and try to by-pass their efforts.  Some people just do not want to be reminded that they are wandering through the office naked.

Why does someone choose this lonely and often frustrating path?  I do it because I think that an office should be a more humane and satisfying place to work.  I want to build software which works and that helps people.  As long as I am an agile professional, I will continue to feel this way with both my day job and my current business.  There is a better way and I am going to find it.

Until next time.

Why Software Development Fails.

Software development does not have to be
a train wreck.

The greatest thing about the internet is that you are exposed to the wit and wisdom of countless professionals.  When you gather together a bunch of these people we want to talk about what we do for a living.  It is just a natural extension of our identity.  Firefighters talk about firefighting, cops talk about police work, and gather together a bunch of elementary school teachers and the topic of teaching will always come up.

Last week I was exposed to a great blog article from Headspring consulting.  In it, they talk about the latest report from the Standish group.  Software developers are getting better at delivering products on time and on budget, but the success rates still resemble batting averages from baseball instead of a mature industry.  This week I want to discuss this blog and why it is so damn hard to write software. 
The present success rate for software projects is still below 50%.  This means if you are a business owner you have a less than 50% chance of a project coming in on time and on budget.   I have to agree with blog author Jeffrey Palermo, this is unacceptable.  This is why I suspect that many business owners do not want to spend money or time on software and technology because they know that the investment is risky.

I have a few theories why software is so risky.

First, software is the only technology product which is not automated.  Computer, smart phones, and mice are all manufactured on factory assembly lines.  Software is created by a bunch of engineers by hand.  This process is similar to writing a novel but it is done by committee and under often unrealistic deadlines.  This hand crafting of software means that there are no standardized parts.  So communicating with a database can be done a myriad of ways instead of one standard fashion. 

Next technology environments are heterogeneous.  It is common for a large company to have servers which run UNIX, desktop computers which run windows and staffs which have Android phones.  This means that software developers spend a great deal of time fitting square pegs into round holes.  The data on your UNIX servers needs to get on your sales forces smart phones.  It is up to your software developer to figure that out.

Third, software engineering is a craft that needs to be learned on the job.  When you hire a welder, you know that if he is hired from a union that he has spent countless hours training both in the classroom and mentored on the job.  The same holds true when you hire a plumber.  These trades have long apprenticeships where the skills to succeed on the job are taught by more skilled artisans.  Sadly, no such system exists for software engineers.  Entry level developers can be self-taught or they can be graduates from prestigious programs.  This means that no two developers are going to have the same base knowledge.

Next, there are so many different languages and design patterns for software development and no one agrees which is best.  If you want to start a fight among software developers mention that Java is a superior language to C#.  Developers are very territorial about their skills and if they are confronted with individuals who don't see design patterns and languages the same way there is going to be conflict and non-cooperation. 

Finally, many of the people who lead software teams do not have any knowledge of how software works.  If you are going into surgery you want the lead surgeon to be a doctor just like the other surgeons.  In technology, you often don't have a software engineer leading the project.  You have a manager with project management or sales experience.  This means they do not understand the challenges of the people who are actually doing the work.  It also means that they do not have the skills to help a team when it becomes "stuck" or faces unrealistic combinations of resources, time, and money. 

This is one of the reasons why I founded E₃ systems.  I wanted to do software development properly.  Since we have launched the company we have gone through two major revisions to our Sully Business Intelligence Platform.   We do an upgrade on average every three weeks and each time a potential customer has asked for a feature we have delivered it in the next release.  We are pretty proud of that record and if you would like to know more you can contact us here.

So you can take your chances developing your own software and have a less than 50% chance of success or you can hire a team that does software development the way it is supposed to be done.  I hope you give us a call. 

Until next time. 

Our New Website

Dude Nice looking website.

Rebuilding a web site is a big deal.  It is not undertaken lightly and usually includes a committee of people attempting to be creative.  I hate redesigning web sites because everyone seems to know how a web site should look but many people do not understand how to make it happen.  This leaves me confronted with power point slides and Photoshop graphics with marketing people telling me that it should look exactly like the file they sent me.  Thoughts about cross browser compatibility and how the site should look on a mobile phone seem like secondary considerations.  It was a website redesign which finally pushed me over the edge and convinced me that I should be an entrepreneur.

It has been almost a year since I formally founded E₃ systems.  When I did I had a clean and easy to understand website which leveraged the latest web technologies and looked good on all the major browsers.  I decided to ignore IE6 because Google and Yahoo decided to. I was pretty proud of it but I knew as we were reaching our one year anniversary we needed a refresh. 

I took inspiration from Microsoft's MSDN website.  The good folks at Redmond are getting ready for the fall release of Windows 8 and are slowly changing over their web sites to have a more metro look and feel.  I decided that I should do the same.  This biggest challenge was finding an easy way to create the tiles and icons used in a Metro layout.  Searching around Microsoft's blog network, I was pointed toward a company called Syncfusion and they had a tool which manufactured Metro style tiles.  Armed with this tool I began the site redesign. 

To avoid making the swap too jarring, I decided that I would only change the front page of the web site and keep the remaining pages in the same format with Metro style flourishes.  I also wanted to make sure that users of the web site had access to all of our social media venues including our YouTube channel.  I also wanted to see if I could leverage the grid 960 css frameworks.  It was like putting together a complicated puzzle which would better appeal to our customers. 

The results speak for themselves.  The landing page contains all the information which old landing page did.  The social media icons are not as distracting.  Users do not have to scroll through the page to digest all the content.  It also looks good on tablet computers and PC's. 

Look over our web site and let us know what you think.

Until next time.

Change is good.

Windows 8 gets my attention like a great pin-up girl.

If there is any constant in the technology industry it is change.  Seven years ago Mark Zuckerberg was a misfit Harvard dropout with a clever PHP application. Today, he is the CEO of a multi-billion dollar company and a newlywed.  In my lifetime, telephones have gone from being dumb devices tethered to walls to portable computer weighing ounces which can call from anywhere.

I spend much of my time struggling with these changes; Enitity Framework, MVC, and HTML5 are just some of the monsters I grapple with to stay current with latest technologies.  I feel like I am being pulled like taffy.  As a technologist, I have to do this because if I don't I will relegate myself to unemployment. 

One trend I have been noticing is that mobile phones and tablets are becoming more powerful.  This power means that tasks which used to require a bar code scanner and a computer can now be done with a mobile device.  This is why to ignore mobile application development is something that developers do at their own peril. 

This is one of the reasons why I am so excited about JQuery Mobile and MS Tag.  The former makes it possible for a web developer to build mobile applications and the later makes bar code scanning obsolete.

In the next ten years, you are going to see smaller and smaller devices doing more and more.  Personal computing is going to resemble carrying around a notebook or clipboard.  If you have any doubts about this just look at the gamble Microsoft is taking with its Window 8 operating system.  While it works on a desktop or laptop it is really made for tablet devices and phones. 

If I am going to survive, I am going to have to learn the Metro way of doing web development and building applications. 

Change is constant and I wouldn't have it any other way.

Until next time.

Bastard Spawn of a Development Tool.

Not bad for a bastard.

One of the basic truisms of technology is that any solid professional relearns their job every eighteen months. Based on that reckoning I have had to retrain myself nine times during my career. It is not pretty and it can be mighty humbling. I complain about the process on a regular basis but I also understand it has given me a modicum of independence and a living wage. This constant struggle of competence is just a fact of life in this business.

I am going through a similar transition right now as I learn how to run my own business and master this funny technology known as MVC. In this blog, I want to talk about MVC and how I am starting to slowly like this bastard child of PHP and ASP classic.

MVC stands for Model View Controller and it is touted as different means of building web application in the ASP.NET framework. MVC partisans claim that this approach better supports test-driven development, total control over HTML generated on the page and divides complexity of the application into meaningful chunks.

When confronted with MVC3 in August 2011, I felt a wave of despair because it looked like I would have to unlearn everything I have ever done with web development over my entire career. It also did not help that my manager used to say things like, "..of course you don't know any better you are a web forms guy."

Instead of a page with code behind as is typical in web forms, I had a controller which handled the http behavior, a view which had no server controls , and models which are nothing more than classes which are passed between the controller and view. Even the markup on the view seemed alien looking like old ASP classic.

Matters were made worse by MVC3's steep learning curve. Unlike web forms which allow a gradual learning process from entry level developer to master. MVC demanded you code a particular way right away. It felt like learning to fly in an F-15 fighter jet instead of a single prop Cessna. It was maddening being given tasks in MVC which would have taken me hours with web forms taking days and weeks.

Over the last six months I have gone from completely helpless with MVC3 to an entry level developer. I still feel that the training books out in the market need to be better to help web forms developers make the transition. I also feel that Microsoft and its partners could provide more classroom style training to get developers up to speed. If I ever get a chance, I might write a book on the subject.

Complaints aside, I have learned to like MVC. Thanks to MVC3 and JQuery mobile, it is easy to write mobile application. They do not even need to download an application. Just fire up the smart phone web browser and you are in business. I also like MVC3's ability to finely control HTML so that CSS and JQuery behave in a cleaner fashion. The security model of MVC 3 is exactly the same as web forms which allows you to use the same security for a web forms application as a phone application. Finally, MVC has forced me to be a better object oriented developer and improved my LINQ skills.

I may be just a "web forms developer," but I understand where MVC fits in the pantheon of web development. Barrowing from Greek mythology, the hero Perseus was the bastard son of Zeus and Danae. Somehow in spite of his questionable upbringing, Perseus turned out OK. I expect similar things from MVC.

Until next time.

Sometimes you can't fake it

Sometimes you can't fake it.

Software developers by their very nature are creative people.  Ask us to solve a problem, and depending on whom you ask you might get thousands of different answers ranging from something overly complex to something elegantly simple.  It just depends on the problem and the person solving the problem.  Business is much more complicated than engineering because we are not dealing with technological problems which tend to follow set laws of physics, chemistry, and mathematics; we are dealing with human emotions and money which can be far from rational.

This is why I enjoy reading the opinions and experiences of other entrepreneurs.  You can learn a lot from others.    Andrew Thomas posted an interesting blog about Lean Startups which had a very intriguing title “Fake it Before You Make It”.  In short, Thomas argues that before you even have a product to sell customers, the budding software entrepreneur should mock up some prototypes or wireframes to generate customer interest.  Then based on the customer feedback you build a product and close the sale. 

For someone who has been in the business a while, I rolled my eyes and bit my lip.  Thomas’ ideas sound suspiciously like vaporware.  For those not familiar with the term, it is that interesting sub-set of computer programing that exists only in the imagination of a sales person or marketing professional.  It doesn’t exist.  It doesn’t work and it is unethical.  Businesses and consumers have been swindled out of millions of dollars by vaporware.  In fact, each year Wired Magazine honors the most egregious examples ofvaporware nominated by its readers. 

Digging a little deeper into the blog post, the author clarifies his position saying snip:

“Just to be clear I nor anyone in lean startup is advocating deceptive practices or vaporware.”

This is good.  It is nice to see that people who advocate lean practices are not saying you should fly by the seat of your pants. 

I am still deeply skeptical of this “fake it,” approach.  I am going to be launching my own company website in the next two weeks.  It works and so does the software application I am selling.  It is not complete or perfect but it is good enough to start showing clients.  They can lease my cloud services as is or if they want to customize it they are going to have to pay for the iteration.  I also plan to add other features in the future like Microsoft Tag technology and a logbook application for over the road truck drivers.  Currently, these new features exist only on paper, but they will be added on to the existing application in a modular fashion. 

I think it is more important to the lean software development process to use scalable architecture and object oriented design in order to grow in a quick and sane manner.  That way it is not a big jump from prototype to working software.  In addition, sales people must be trained to avoid making promises and then forcing the software developer to keep those promises.  There must be a financial risk to someone who oversells your product.  Thus, if a sales person mocks up a Power Point or Visio document of  what my software can do to a client and I don’t know about it someone is going to be docked a few percentage points of commission.  Sales and technology must work together. 

I feel that I have put together a lean and mean company so I don’t have to “fake it” in order to close some sales.  I realize that I will have to do some prototyping and that on occasion a sales person is going to over promise.  That said, I think the best approach is to have a few stakes on the grill before I start selling the sizzle.