I can’t think of a better position. Finding problems in potential markets, helping design solutions, and delivering. Not sure if all developers find this path exciting, but I certain do.
I have worked for startups nearly my whole career. It’s fascinating to think about all I’ve learned over the years.
I might blog more about this.
Your business owner, client, customer wants a certain app built, with certain features, for a certain market
Specific software: Specific software can be used for a specific purpose.
Abstract software: Abstract software cannot be used for any purpose, but after configuration, it can do anything
What does the organization paying for your services want? A specific set of features that can be delivered to a market, tested, iterated, and tuned to add value for everyone.
What does your programmer want to build? Might be abstract software. Building a configurable solution is very tempting to the developer. It is challenging, complex and engaging. It lures the developer in promising huge scope of application deployment.
What are the challenges to abstract software? I’ll list what I’ve seen over 20+ years developing software.
1. Who does the acceptance testing on abstract software? The business owner could test the configured end product, but often hasn’t a clue how a configurable abstract solution should work.
2. How much documentation do you want to write? Each specific version should get some words about use. But, what about this abstract system? How do you configure it? The “admins” will need to know.
3. Automated testing? Testing for specific use cases is deterministic – you test for clear expectations. It is also of manageable scope in relation to the app. Abstract software can have so many happy cases, and alternate flows to make it substantially harder to get the coverage needed to ensure quality.
4. Time to build. The man hours to built a generic solution is at least as long as a specific solution. But, remember, you don’t have a product yet at that point. You still need to configure the solution which will take time.
5. Perception – Reality problems. Unless your client is very knowledgeable, there is a risk that when the programmers say they are done coding, the business owner will expect something to deliver to market. The programmer, with a deep understanding the code will think configuration is a simple exercise, while the client may see it as a incomplete product.
One way to mitigate the risk is to built specific first. Use modern approaches like Lean Startup and Pretotyping to tune your specific solution to a specific market. Once you have established success in that market, consider factoring out areas of code, and creating an abstract solution to be configured for other similar markets.
If you decide to build something abstract, know what to expect, and be sure to hire a big enough team to get it all done.
For a long long … long time I road a 26 inch wheel bike. I’m nearly 6 feet tall. Around the year 2000 is when I remember 29 inch wheel bikes becoming available. I even considered getting a frame built by Matt Chester, the Ti frame builder, who insisted I ride a 29er. Looking back I should have taken him up on that. At that time it was hard to find tires, or so I thought, so I passed. Opted for a surly 1×1.
Recently moving back to the States, I had the opportunity to go shopping. Was time to try out 29 inches finally. I picked up an SE Stout. Not a big investment. But big in results. I love it. If I ever call Matt up again for a frame, I’ll want him to consider the geometry of this bike.
So here are my reasons to consider riding a 29er.
1. More foot print in the corners. You can rail around corner with less pressure on the bars which allows for tighter turns without the risk of washout because more tire is on the trail.
2. You can run rigid forks where you used to run a 100mm fork. We all know that the bigger wheel rolls over bumps better. But, what this means is you can run a rigid fork which is lighter, cheaper, easier to maintain, and doesn’t move around underneath you. The biggest benefit is no sinking of the front end in the corners, or weird unpredictable movement from a shock.
3. You can roll over things much easier with the bigger wheels. Can’t count how many times I’ve hit something while riding my 26″ bike causing my front wheel to bury in and nearly stop turing. I’m routinely amazed what I can roll over on a 29″ wheel.
4. Stability from the bigger hoops builds confidence. Bigger is just better.
5. No longer look like a bear on a bike. If you are big, face it, this size bike is for you.
Well, it’s not for everyone though.
1. Shorter people probably less likely to benefit. But, that is no flat rule. My all means try it out.
2. Harder to fit in your car, and on some racks.
Hope you enjoyed this rambling.
A good sw manager simply helps motivate a developer so that coming to work is a joy. Not all managers can do this. But, as a developer, it’s important to work hard, don’t complain, and deliver the code, at all costs.
It is hard sometimes, but that makes us professionals. We take the good with the bad.
Good management is a dream. A good manager can actually cause you to work overtime by not even asking. A good manager can keep you excited about a project, and keep you there until it’s delivered.
Opinions are cheap. Listening is key. So, perhaps by blogging, I’ll get out my thoughts and opinions out of my head in an more opt-in manner. That will let me spend more time listening to all the interesting things said by others.
In this blog, you can read about my experiences, opinions and interpretations aimed at how they effect other people, software projects and other random things. You can expect to read balanced, thoughtful information. You will never see a rant or complaint. But, sorry, I can’t promise my posts will be interesting or at all informative, thought I will try.
I am a seasoned generalist software application developer, software architect, and wannabe team lead again.
What to How To - Software and more 