Category: General Information

Morally Lucky Software

As a culture we are highly focused on results and less so on the path to the result. You can see this mentality throughout our laws.

For example given two drunk drivers going home, the first driver gets caught and recieves a DUI, while the second driver as a result of being drunk hits and kills another driver will get charged with both a DUI and manslaughter. Now both drivers took the same risks and for chances not under their control had two different results, while we can morally blame both drivers for the same actions we choose to punish them differently.  This is refered to as resultant moral luck, are you building your software with it?

Just because you delivered software last time that was on schedule and worked correctly, was it just moral luck? Knowing that there are ways to improve your development process and improve your code quality as to reduce the risk involved in creating software, are you still not using them? Not using them is not calling your friend to drive you home from the bar, yes you know its a good idea but you got home safely last time so you don't need to this time.

Should you be accepting moral praise for a project from the business, when the result was less in your control then it could have been? Clearly building a trivial website for a hobby has minimal risk but if the software you are building for a business is of importance, must you wait for a the dice to come up against you before you try to do better?

Did you like this? Share it:

It’s Time To Call BS On The RFP Process

“Will you be able to bid by the 20th, so we can accurately plan the project timeline, budget and compare all bids?”

“Please include SDLC phases, a project timeline in months, your roles for this project, total hours to complete the project and grand total price.”

I had imagined that the dysfunctional days of the RFP (Request For Proposal) in software development were gone. Man, was I surprised to see an Executive-level IT Manager still committing the irresponsible mistakes that have driven software development projects to failure over the last 40 years.

So who uses the RFP model? Where did it come from?

1)      Construction industries – who have known, repeatable processes with supposed predictability but who still have a 90% failure rate on estimates.

2)      Sleazy sales people – who are not interested in software value – only their commission.

3)      Government – whose addiction to waste should never be used as a business model.

And we all know this negligent game – toss out the lowest bid, toss out the highest bid, haggle on rate, fabricate timelines, pad estimates, rush to an arbitrary deadline, work 80 hour weeks and then celebrate project survival.

But what are we really bidding on? A contractual guarantee that change won’t occur or that punishment should ensue? And what if change does occur during the project?

An RFP will guarantee you fixed time and cost, but here’s what else it will guarantee you:

Waste. 68% of IT projects are NOT completed on time and budget. (Only 32% of IT projects are completed on time/budget, 44% are completed late and over budget and 24% are abandoned. Source: Standish “Chaos Report” 2009.) You are not exempt! Your RFP will ensure your inclusion in this statistical failure – despite your belief that it’s the remedy. The RFP is part of the continuing cause of these wasteful company practices. Can you really afford to be a statistic in this economy?

Disgruntled Developers. The inability to move a timeline or cost means employee overtime to meet what was well intended guesswork on software that hasn’t been created before. Good developers in the .Net space are a rare commodity. Treat them well. They are almost as recession proof as beer and can work almost anywhere they like. Managers/owners who view them as replaceable commodities will deservedly incur the cost of knowledge loss and replacement learning curves.

Disgruntled Employees. Change is inevitable and it’s a naïve manager who believes that employees won’t go directly to developers to secretly request changes to their original scripting in that almighty RFP. It just means the developers will have to sneak it in and work longer hours to help out the users. They both know they’re on the same team… Why don’t YOU?

Disgruntled Accountants. Sure, you’ve made the accountants happy up front with the RFP temptation of “set-it-and-forget-it” budgetary “predictability”, but experience should tell you that you have created an inherently wasteful, poor quality product that will have ill-effects beyond delivery….perhaps even before delivery. The accountants will ultimately be disgruntled because what they thought was a finished product is not. In fact, many more maintenance projects will amount to many times more than the original RFP. The cost of that original RFP will also spill into other projects in the form of Technical Debt.

Disgruntled Customers. Fixing project cost creates measureable business cost in the form of customers who prefer to use your competitors’ products. It doesn’t matter if your customers are internal (employees) or external paying customers. Your “internal customers” will pass on a poor software experience to your paying customers. (How many times have you had that experience passed on to you over the phone? “I’m sorry, the system isn’t able to …”) You will pay for it either way. RFP’s ensure that customer-driven requirements will take a back seat to the time/cost commitment of the almighty RFP. A company’s inability to adapt “the plan” and pivot/respond to real business customer feedback cycles guarantees poor quality software and a poor client experience.

Disgruntled Ownership. Antagonistic relationships between developers, employees, accountants and customers make for disgruntled Ownership. Creating a company quagmire from an RFP seems at odds with good entrepreneurship. If you are a business owner, and your IT manager is proposing a model like an RFP – understand that it is at odds with the very nature of software.

Fired Managers. Managers playing the RFP game are not interested in value…only cost. They are interested in following the plan – not the ability to respond to change. They are more interested in comprehensive documentation – not iterative working software. They are more interested in contract negotiation – not customer collaboration. These are all things that the Agile Manifesto addresses. Do yourself and your career a favor. Learn better software philosophies. It will save your job.

RFP is NOT the right model for software development.

And it never was! IT professionals have always known the irreconcilable disconnect between guesstimates and the reality of coding. Listen to them!

Let’s stop this awful, wasteful practice. We’ve learned so much from the failures of this system to be perpetuating this harmful, wasteful approach to software development in this economy.

I have an idea. I’d like to redefine what RFP really means to companies. Here’s a handful of options – feel free to add your own.

·         Requesting Failure Please?

·         Recreate Former Problems

·         Ready For Pain?

·         Request For Panic?

·         Request Flawed Performance

·         Request Flatulent Product

·         Run For Parachute

·         Randomly Formulated Plan

·         Really Faked Projections

·         Reassess Failed Philosophy

·         Restart Failed Project

·         Random Firing Permitted

·         Repress Future Profitability

·         Rewrite Forced Programs

·         Rework Fanatical Projections

·         Remember Former Pain?

·         Recently Failed Project

·         Refund Financial Profit

·         Regret Faked Promises

·         Richly Formed Prank

·         Relic From (the) Past

Did you like this? Share it:

Are You Looking For A “Hero Developer” Or A Consultant?

Let's take a quick look at a scenario that happens all too often in the business world…

1.       Company has process/culture problem.

2.       Consultant brings in new process.

3.       Company loves new process.

4.       Process fixes problem.

5.       Consultant becomes hero.

6.       Company thinks Consultant IS the process.

7.       Company becomes dependent upon Consultant.

8.       Company doesn’t want to let Consultant go.

When it comes to software developers, we live in a town that gets attached to individuals.

Often we start as consultants and over time bleed into staffing models.

It’s somewhat revealing about what clients truly want.

And it’s cultural. It has to do with trust and execution. After being at a client for awhile, the Consultant's messages – and what their Company stands for – become replaced by the hero culture of the individual.

There is a portion of this that’s knowledge work and we fear that change of personality presents a loss of that knowledge. We worry that it will create uncertainty in our daily continuity. That’s understandable. We start to imagine that the daily operations of the new process can’t operate without the Consultant on hand to make it tick. But other individuals have knowledge too, so perhaps the real fear is that we might be losing someone who can save us in dire circumstances.

The fear of losing the hero as our "Ace in the hole".

The intention of having a consultant should be to help companies course correct and become self-sufficient with new approaches.

If you’ve had a rock-star IT consultant come in to help with your internal pictures, at some point he or she should be able to put themselves out of a job. But the opposite invariably happens and Dependency situations arise instead.

Companies lose sight of the original intention, and the consultant gets swallowed up in the process they’re attempting to correct and the message is lost. The Consultant becomes a daily grind "fix-it-all" super-hero – strapped to the process they’ve been hired to provide assistance with.  

We get tied up in the achievements of the individual, and not the philosophies they brought to the table. We start treating him or her as a great developer who can get more work done than their peers, and the Consultant turns into a “Butts in Seats” contractor. We lose sight of how they were able to achieve success. In fact, we don’t really care. Ultimately, we just want it done for us. We want the hero to arrive to save us from the very same poor decisions we were asking them to originally help us with.

We want the Consultant to save us from ourselves.

Focus instead on what the Consultant is telling you – the process improvement and self-sufficiency. Not the hero that made it happen. Listen to what he or she is telling you. Don’t just watch them execute and absolve yourself of the responsibility of learning what they are attempting to teach you.

Instead, up your own game. After all, that’s what the Consultant was originally brought in to do, right?

Did you like this? Share it:

What Should You Look For In A Software Development Mentor?

Post written by Brett Gibson, Owner at AdventureTech

Every day I see more and more developers becoming agents of positive cultural change in their own organizations and IT communities. Either by nature or occupational hazard, we enjoy problem solving. It’s just how we tick.

Because software touches every aspect of a modern organization, our opinions are being sought to help solve larger systems pictures. As we do so, mentors and thought-leaders have become an indispensible part of that transformation to better practices.

Developers are in a constant learning culture and it can be an overwhelming experience for new developers to even know where to begin. Given the pace at which new technologies and practices arrive and the breadth (and depth) of knowledge we’re expected to retain, ours is an industry that benefits immensely from mentoring.

Mentoring assists with technology, practice and process learning curves, team cohesion, software delivery, stakeholder engagement and employee retention (something that all IT departments face).

Rather than tread ground that’s already been walked before, a mentor will show you solutions that have already been formed and help you avoid technical dead-ends that have already been taken. It can also help a company avoid Technical Debt born of rookie mistakes.

So what are the qualities you should seek in a mentor?

1. Seek out a subject matter expert (if one exists) in your area. Someone who has invested the time it takes to understand something deeply.

2. Seek out someone who actually practices what they preach and who can explain why alternate approaches might fail. But beware of a mentor claiming subject matter expert status in a technology that’s 10 years old… We call that archaeology.

3. Seek out developer mentors who are the communicators in your discipline. The ones who publically speak and blog are excellent choices because they’re brave enough to publically stand behind their facts and convictions.

4. Seek out developers who are trying to address larger industry dysfunctions like Agile, Lean, Kanban. These are your thought-leaders. They are the ones attempting to make this industry a better place to work in. They are the culture changers – the ones who can help with larger company pictures.

5. Seek out a mentor who is also focused on community. We’re fortunate in Kansas City that the developer community is so actively collaborative in nature.

Good developers love to learn and share it. Good mentors show up.

Here’s a quick list of groups and events that you might think about checking out. This list is not exhaustive, but a great starting point if you’re wanting to find a mentor or simply become more active in the community. 

Kansas City Developers Conference – A yearly event not to be missed. Mentors, MVP’s, speakers, bloggers, experts galore.

Limited WIP Society Kansas City - A monthly meet up for developers interested in the Lean and Kanban software development. A great roundtable on topics suggested and voted on by those who attend. Moderated by Troy Tuttle.

Kansas City IT Professionals – Run by community advocate Mike Gelphman. Mike also runs the most active IT LinkedIn group in Kansas City.

KCNext – Recently merged with SITAKS serving as a regional advocate for KC Tech companies.

Did you like this? Share it:

My AdventureTech Experience: A Post From “The New Guy”

Post written by Joseph Davis, Web Application Developer at AdventureTech, AKA "The New Guy"

I first came in contact with AdventureTech in September of 2011.  A good friend of mine, Donald Rossberg, had been attending a local business networking event where he met and became acquainted with Brett Gibson, one of the owners of AdventureTech, who was also attending the event. When Donald found out I was passively seeking a new opportunity he arranged a lunch meeting for the three of us so I could meet Brett.

Brett was a very talkative and friendly fellow. One thing that immediately stood out to me in his conversation was his deep interest and understanding of agile development principles. I could tell from the depth of examples he spoke of that, to him and to AdventureTech, “agile” wasn’t just some buzz word they adopted for a season. Instead, it was something they had successfully implemented, that they believed deeply in, and that they had enhanced through multiple experiences with clients.

Some time later I ended up in another lunch meeting, this time with several of AdventureTech’s developers, including Phil Ledgerwood, Troy Tuttle, Lee Brandt, and Brian Moon.  I was prepared for a technical drilling as is common with many panel interviews I’ve been through in the past. Instead it seemed they were more interested in telling me about themselves as a company, what they were all working on and what tools they were using in their various projects.  

They spoke of Inversion of control containers, object-relational mapping tools, test driven development, and other design and development patterns. Many of these were tools and practices that I had read about and of which I had a fair level of theoretical understanding but had not had the opportunity to put into practice in a professional work environment. The prospect of doing so was very appealing to me.

Until just recently, the team of developers at AdventureTech was composed entirely of very experienced senior level developers, many of whom are involved in the community and give talks at development conferences. Such was their culture and the nature of their team.  Now they have begun bringing on some younger developers with the intent of molding the next generation of senior level industry leaders in Kansas City.  

They aren’t looking for developers who already know it all, but instead they want people with an aptitude and thirst for learning along with good communication skills. One thing I heard a number of times during the interview process was: “How to write good code? That’s easy to teach.  How to teach a person to have good communication skills… that’s something they should have learned in kindergarten."

I’ve been with the team for about a month now and am pleased to report that it is turning out to be everything I was hoping for.  Many of the other guys on the team have titles on their business cards like “Software Practice Coach”, “Software Process Coach”, and “Developer Mentor”.  I find myself in a place where learning is fostered and supported, and I’m picking up many new things each day.  I feel empowered in this environment to be the best I can be and I’m very excited about the future of my career.

In addition to fostering learning and encouraging the use of new tools and technologies, AdventureTech also strives to create a compelling work environment and benefits package that will draw the best developers around. Apart from very competitive compensation and medical benefits, AdventureTech also provides an education and equipment budget so developers can stay sharp, and an extremely generous amount of Paid Time Off that I have only seen matched by some companies for their employees with decades of tenure.

Although I’m still fairly young in my career, I have been through several jobs looking for a place that had everything I was looking for.  I’ve finally found that place and I’m proud to be a team member at AdventureTech.

Did you like this? Share it:

Connect With Us

     

Contact Us

Toll Free: (888) 373-8718
Main: (913) 402-9600
Fax: (913) 402-9603
7450 W. 130th Street
Suite 320
Overland Park, KS 66213

Upcoming events

  • Events on May 16, 2013

    LWS Lunch

    Starts: May 16, 2013, 11:30 am

    Ends: May 16, 2013, 1:00 pm

    Location: DEG Offices

  • Events on June 18, 2013

    Kanban Training

    Starts: June 18, 2013, 12:00 am

    Ends: June 20, 2013, 12:00 am

  • Events on June 20, 2013

    LWS Lunch

    Starts: June 20, 2013, 11:30 am

    Ends: June 20, 2013, 1:00 pm

    Location: DEG Offices

  • Events on July 18, 2013

    LWS Lunch

    Starts: July 18, 2013, 11:30 am

    Ends: July 18, 2013, 1:00 pm

    Location: DEG Offices

  • Events on August 15, 2013

    LWS Lunch

    Starts: August 15, 2013, 11:30 am

    Ends: August 15, 2013, 1:00 pm

    Location: DEG Offices

  • Events on September 19, 2013

    LWS Lunch

    Starts: September 19, 2013, 11:30 am

    Ends: September 19, 2013, 1:00 pm

    Location: DEG Offices

  • Events on October 17, 2013

    LWS Lunch

    Starts: October 17, 2013, 11:30 am

    Ends: October 17, 2013, 1:00 pm

    Location: DEG Offices

  • Events on November 21, 2013

    LWS Lunch

    Starts: November 21, 2013, 11:30 am

    Ends: November 21, 2013, 1:00 pm

    Location: DEG Offices

  • Events on December 19, 2013

    LWS Lunch

    Starts: December 19, 2013, 11:30 am

    Ends: December 19, 2013, 1:00 pm

    Location: DEG Offices

  • Events on January 16, 2014

    LWS Lunch

    Starts: January 16, 2014, 11:30 am

    Ends: January 16, 2014, 1:00 pm

    Location: DEG Offices

  • Events on February 20, 2014

    LWS Lunch

    Starts: February 20, 2014, 11:30 am

    Ends: February 20, 2014, 1:00 pm

    Location: DEG Offices

  • Events on March 20, 2014

    LWS Lunch

    Starts: March 20, 2014, 11:30 am

    Ends: March 20, 2014, 1:00 pm

    Location: DEG Offices

  • Events on April 17, 2014

    LWS Lunch

    Starts: April 17, 2014, 11:30 am

    Ends: April 17, 2014, 1:00 pm

    Location: DEG Offices

  • Events on May 15, 2014

    LWS Lunch

    Starts: May 15, 2014, 11:30 am

    Ends: May 15, 2014, 1:00 pm

    Location: DEG Offices

Recent tweets