Work Isn’t Fun but It Has Long Lasting Benefits

I'm skipping the Huskies basketball game right now and playing with friends because I am trying to help my buddy with his business. There are sacrifices that come with doing good. Working on my buddy's problems makes me feel happy and like I am doing something good. The Huskies will win or lose, my friends will (hopefully) still be there for me, and I am feeling better by contributing to my friend's business. Social to me is helping other people, not necessarily drinking or watching sports with them although that might be more 'fun'. Fun creates a short-term reward. Work has lasting benefits.

Remove the Immediate Business Process Bottleneck

Nothing more to say here, really. As a developer, you are coding for one purpose: remove the most urgent and important business problem that exists. You are fighting fires all the time but you may not realize it. If you're not, then become a better business analyst. You are trying to free business resources so they can do more value-added things.

The ‘Holy Trinity’ of Economics: The Customer, The Product, The Supplier

The goal of providing products is to create dependence on the supplier by the customer. The customer will use the product to solve his/her problems and hopefully return to the supplier when he needs something else or something more because the supplier was the one who helped him out in the first place.

Build Small Bridges

You might care, I might care, but how do we make 'everyone' care? It's impossible. We can't. We can attempt to add one person at a time to our way of believing. But most likely--by the time we reach the last person--our thought process and beliefs will have changed so drastically that our purposes will shift. It's like painting a bridge: by the time you're done, it's time to start over again from the beginning and repaint. Make your bridges small. Build many bridges. And be flexible.

The Role of ScrumMaster / Software Development Lead / Manager

Remove impediments, improve the process. Understand what's being added to the backlog. Understand what kinds of "shortcuts" or workarounds are being taken by the team. Understand the consequences and better solutions to these items.

Plan for the next big problem

The stuff you're doing now will likely amount to something bigger and better once you're done. Keep doing what you're doing and getting better at it but keep in mind that there are consequences of what you are creating. Prepare for the consequences and get ready to tackle the next big problem they create when you get there; but only then.

Make the development process be THE KEY PROCESS

Development speed and efficiency might matter more than anything else. Yes, customer requirement and needs are paramount in general, but sometimes they are unclear and the development team can produce something really good that isn't EXACTLY what was corrected. This discrepancy is fine. If the development team can produce Product X which CLOSELY RESEMBLES the 'perfect product' described by the customer, then that is the product that should be produced. Future iterations can make it perfectly align.

Efficient workflow tradeoffs and cost

Workflow can be seen in two ways: that of the SYSTEM USER and that of the DEVELOPMENT TEAM. The end goal for most projects is to create a "perfect and efficient" workflow for the user. Being efficient may involve trade-offs as there is a cost for realizing perfect workflow. If the development team isn't paid for the realization of every incremental user workflow bit, then there is a problem.

Use the skills you have now to add as much value as you can now

Don't get bogged down doing a bunch of boring repetitive stuff now unless it is required. Follow the Pareto Principle http://en.wikipedia.org/wiki/Pareto_principle and knock out the big stuff. Demonstrate as much value as you can. Solve the problems you know how to but don't solve them throughout the whole system just yet. You can do that later. Yes, you'll develop a backlog of little stuff that has to be fixed; the time will later come when that is urgent.

Computer Programming is a Slow (, Fun?) Learning process for me

Yes, for me it's a very, very slow, tedious, painstaking one requiring much patience but the rewards seem to be many: it's very, very fun to learn so much and build a war-chest of solved problems that you can apply to the next situation. It's never-ending.

You learned it generally now, take the chance of applying it later

Any time you're unsure if adopting a new practice will help or hinder, don't adopt it. Go down the road on this project with the skills you have today and apply what you learned to the next project or iteration. Learning along the way is most of the fun but we don't have to apply everything we learned / are learning to our current project. We can do that later, in a future project! If you add the things you're learning to this project, you'll never finish; the project will grow and grow.

Today I'm working on a software app for my buddy Andrew. I'm having fun but the going's slow at times and I don't know everything. It is a forms application and the technology I've chosen to use is ASP.NET MVC (http://www.asp.net/(S(d35rmemuuono1wvm1gsp2n45))/mvc/) which I think is basically amazing, but I'm still learning it. In trying to solve the problem at hand, I read some VERY neat-sounding techniques from Brad Adams (http://bradwilson.typepad.com/blog/2009/10/aspnet-mvc-2-templates-part-4-custom-object-templates.html) on automating form creation in ASP.NET MVC but I don't want to increase the scope of my project; I've got to finish knowing what I know now. I don't want to go down this rat-hole.

Brad's techniques look awesome and like they could save me a bunch of time later, when I have it. But I'm not going to invest in learning it now. I'll plod forward using the skills I have. I'm not a hacker, I am a software developer trying to produce working software as fast as possible. I'm not going to indulge in research activities right now.

Doing anything by yourself is very hard and there's always a better way to do something. There's always something to learn. The lessons we learn on our current iteration or project can be applied to our next iteration, later, when we have a chance to plan.

What’s a good project / program manager? A stable leader.

Someone who can stay afloat. Someone who is confident in their abilities and methods. Someone who is curious and perceives the world as dynamic and pliable. Someone who likes and trusts people. Someone who things that they and their peers are talented and having fun. Someone who can have tons of stuff thrown at them yet know the way forward and what to do next. Someone who is a planner. Someone with a plan. Someone who can backlog, prioritize and not burn out themselves or their teams. Someone who stresses out infrequently and contains it very well when they are stressed out. Someone who is cool under pressure. Someone with systems, standards and strategies. Somoene you want to work with who will not throw you under the bus or add unnecessary stress to your life.

Sometimes you may want waterfall development; but the luxury will cost you!

Sometimes you simply don't care about the specifics of what comes out the other end of the engineering process. Either because you have high expectations and high trust in what they'll deliver. "High engagement" with the engineering department will cost you time and energy. "Low engagement with engineering will cost you in time and rework, waste, and cost

There are times, like when a business person builds a prototype of a system or clearly defines the product requirements, that they can give that input to engineering to harden and tighten the design. In such a case, the inventor(s) of the prototype or specs may not really care what comes out the other end; their requirements are fundamentally qualitative: 1) Make it look good 2) Make it performant 3) Make it "tight". Managing a project in such a way is possible and sometimes desirable. But there are alternatives.

Not everyone wants to engage with an engineering group in an Agile / High Bandwidth way. They need room and space. They don't want to be an engineer. Weekly check-ins (like in Agile) seem reasonable but maybe some people would prefer monthly, quarterly, or annually. The larger the period between reviews and meetings, the larger the budget, the more the risk, the bigger the problems, the lower the quality.

Technology Things I’ve Learned Recently

Installing and using Eclipse. Installing WordPress and Drupal. Installing Drupal modules. Customizing Drupal. Things about ASP.NET MVC version 2.0. DataAnnotation in .NET. SSIS packages and catching error rows. Silverlight application development techniques. About RIA Services. There's a lot of great stuff out there.

Good Governance is Sitting Down with the Governed

You can write all the rules you want in an attempt to make people comply but the best way to get result and learn from others experiences is to sit down with them. Take the time to do this today!

Modified Version of Alvin Toeffler Saying

Coding is the easy part. The hard part is to discover and apply technologies that can continuously fit the business needs and problems.

The Users Need It Now!

Don't procrastinate. Get the software in their hands ASAP. The business process is the thing that matters and unless the tool or software is in-hand, you won't know what it is and what needs to change. Deliver now.

Hacking vs. Solving Root Cause – Level 1 and Level 2 Problem Solving

Stopping the bleeding and fixing what's in front of you is way different from solving the ACTUAL problem (not surface problem). I'll write more about this soon!

Capabilities Increase Scope

So ultimately it seems that having multiple developers changes the REQUIREMENTS of the solution and for that reason, the velocity. Assuming that all developers are stuck with where they are at with their own personal velocity until they read something great or get help from a peer. So if developer A knows how to do thing M and N and developer B can do thing O, then the total requirements for the solution are likely M, N, and O. For me, I'm operating on M and N now and the solution is "simple". If I could find someone who could do thing O, then it would take longer. Pragmatism is odd.

Individual vs. Team Work Velocity

It'd be very nice to always have a team (or at least a pair) of developers, but sometimes this isn't possible; sometimes we've got to 'go it alone'. I'm doing that right now on an app for my friend. I'm fairly good with the basics of getting things to print on the screen but when it comes to making things elegant and beautiful, I am way weaker. I consider these weaknesses "low pri" but if I had another person looking over my shoulder they may be able to help me. Right now I'm going to punt these things I can't do elegantly and am backlogging them with "TO DO:" statements in my code. This isn't a major concern but it raises the question for me of the difference between an individual and team's velocity. In an idea world, all developers would be able to work by THEMSELVES as fast as they possibly can. But there is overlap often, and people have to help people, and there is a team, so what would the net-net of adding people to a team be? Definitely more communication channels…