

No software development process for startup - What do you think about this? - anonymous-dev

I have been pondering on this for a while and need to get some feedbacks from fellow developers.<p>Here is the scenario:<p>I am a developer documenting what I work on (apis, tools, etc) to. However, my colleagues don't. This have been driving me nuts but I cannot change them (I tried).<p>I also like to improve existing tools (build system/ code base). However, my colleagues don't.<p>Here is what every developer faces every day:
 - No automated build (e.g.: Continuous Integration Server) 
 - Released archived as emails instead of FTP/Nexus like software.
 - Developer builds production releases on their dev machines.
 - Undocumented APIs/build system
 - No automated test
 - No clear roadmap
 - No code review
 - New developers are hired without going through any technical interviews nor have background 
 or experience required (programming language, software dev lifecycle, mindset).<p>The business was not doing well until recently which explains why all those things creeped up (although IMHO, automated build and unit test should be done anyway).<p>Now, the business is doing well, I managed to develop an automated build system after a year or so battling with management and reworking tools to make it happen.<p>New hires are coming in but I feel those processes aren't really used/sought by other developers. Some management folks seems to care  about the issue but don't see the need as much as I do; a strong, well structured yet flexible software dev process is a very valuable asset for any company and should be respected fully.<p>No other developers (about 20) raised any concerns about the current software dev process, only me.<p>a) Am I too impatient since things are slowly changing ?
b) Am I too process oriented ? This is a 5+ year old startup.
c) Am I the problem ? 
d) Is this software shop not a good place to work for and improve one's skills set ?
e) Should I just suck it up ? That's the startup world.<p>I really appreciate your feedbacks.
======
TheMonarch
Have you read the Pragmatic Programmer? They talk about how to handle a
situation like this. From what I remember it said to build a pocket of
excellence in your dev workspace first, and then expose everyone else to it.

Set up the CI/build server on your machine, have it email everyone when the
build fails. They will see the use of the tool then, and when the team accepts
it they will hopefully get an official server to host it on.

Write tests for your code, and when other devs work with you on issues, or
break things, write tests and send to them "Hey, i wrote this test that shows
the code you wrote is failing, can you make it pass?" Also ask others to make
unit tests. You will have to write the bulk of tests. You probably know which
others on the team are open to writing tests and working with you on the
pocket of excellence. Get them involved first, and then the idea will spread.
A good idea would be buy them copies of Pragmatic Programmer too.

No, you aren't process oriented. A software team that doesn't at least like
the idea of automated builds, and tests is crazy. As far as if it's a good
place to work and improve one's skills? That depends. In some teams you might
never get them to adopt the pocket of excellence. If you are working in a
place like that, then it's probably not a good place to work. But if you have
a shot at converting them by just doing it on your own first, then it would be
a great opportunity to get experience with setting up these aspects of a
software shop. And you can put that on your resume, blog about it, etc. In
that case it would be a great experience.

~~~
anonymous-dev
I heard about the Pragmatic Programmer book. I guess it is now time to read
it.

About CI server, it is on its way but only for production release. No
continuous build for now mainly because there is no unit test infrastructure
setup.

About writing test, well, no one uses unit-test for the reason above. It maybe
a good time to introduce that and get to show them the light :)

"In some teams you might never get them to adopt the pocket of excellence. ".
I am a bit afraid of that. Why ? I have spent some time trying to change
things and yet I see little or no effort from others.

What are you thoughts on documenting things ?

~~~
TheMonarch
Very high level documentation is good. Things like, what are the steps to get
the app to build, what tools do you need to install, frameworks, etc. What's
the directory structure, so that a newcomer knows how to approach the project.

I'm a fan of self documenting code. Trying to document code is nice, but
rarely possible to keep up to date. I do like to put short comments on a
method if the name and class its in don't provide enough info. It's better to
spend time writing code and tests than documentation.

You can't always convince people to do things they don't want to do. Some
people don't care about putting more than the minimum of effort into work.
Most people hate change. But if you just go ahead and create the pocket of
excellence, people tend to notice why its good and if you get momentum then
the rest will follow. Who are the influential people on your team who if they
started using these good practices, the rest would follow? How do you think
you should best convince them? For some people, find out what motivates them,
and then see if you can explain to them how adopting these practices would
benefit them.

~~~
anonymous-dev
About the first paragraph, that's exactly what I am trying to get going.

About the second paragraph, I 100% agree with this.

I did create this pocket of excellence (myself only) and lead the way for some
time. Yet no one notices it and the ones who do, well, they don't care about
it - both for junior and senior developers. IMO, the most influential peoples
are so called "rockstar" developers within the company and they clearly stated
they don't see the interests. I already talked to them and attempted to
convince them. I am running out of ideas.

~~~
TheMonarch
Why are the rockstar dev's not interested in things like automated builds, and
unit tests? Are they really "rockstar" dev's? It might be political. Maybe
they like being the only ones who know how to build the product, or that it
has to be done on their machines.

Sometimes people shoot down ideas of those below them because they don't want
to see a "threat" rise up to compete with them. Maybe if you can't convince
the rockstars, just get everyone else onboard.

So you created the "pocket", are you getting anyone else involved? If you
already tried to get official adoption of these practices and that didn't
work, I dunno. You might just get it done. A lot of times managers ignore
requests like this because they don't want to bother with change. THey don't
realize the benefit, or they don't want to try to force change on a team
(maybe they don't want to adopt anything the rockstars aren't into).

~~~
anonymous-dev
"Rockstar" developers are simply jack of all trade developers with the most
experience by far in the company - they created the entire system from
scratch. About it being a political thing, I believe so.

I failed to get everyone else on board (even new hires as per my last
discussion) because they seems to have already pledged allegiance to the
"rockstars" AND/OR don't give a fuck about good engineering/project management
practices. Eg: Some have already told things like "I don't mind having a
commit fixing two issues at once while the bug report clearly specifies to fix
only one of them. I don't mind not raising an issue in the bug tracker about
the second bug I silently fixed".

Some managers are former developers who did implement those practices while
they were devs but they don't see the urge now. Maybe they know they will not
have to fix the issues directly and that might be the reason why they don't
push those changes as much. What do you think ?

~~~
TheMonarch
Well, there is no guidebook for this kind of thing. I don't know what to tell
you. THere are probably people who know how to accomplish what you are trying
to do, but I don't know how to advise you past this point.

The takeaway is that while you sound like you are probably a solid developer
who's passionate about good software dev practices, the thing you need to work
on is people skills, and the politics on how to get what you want. Basically
you have a set of things you want to see done from a tech perspective, but now
you need to figure out how to effect that change in the company you're in.
It's not as easy as it sounds. It's not as easy as explaining the benefits to
people. A lot of times, to be honest, I've felt very passionate about
something and when it came time to try to convince others, I couldn't really
convince them and it was really frustrating. The only thing you can do in
those cases is to learn to be less rigid about it. If it's going to bother so
much that youa re going to keep stickling about it, you might better off
working somewhere else.

I learned that I am sometimes very rigid in how I want things done, but that
is only my idealized version of how thing should be. The rest of the team may
not want to adopt my ideas, so I had to learn to accept that. There is the
perfect way of doing things, an then there is how things are done in real
life. Everyone has different motivations. Sometimes people just aren't into
their software dev jobs, sometimes they just know software as they learned it
years ago and don't want to learn to do things the "right" way, or don't want
to learn new technologies. Sometimes the motivations are political. Sometimes
it is possible. I think it's often impossible to effect change if the
"rockstars" aren't in agreement, often as we discussed before, because they
don't want the guys lower on the totem pole showing them up by improving
things.

It sounds like you have reached a dead end. You can either figure out how to
do it on your own, which will take soft skills. You won't do it by convincing
anyone that your ideas are technically the right way to do things. People
generally don't care about that in the real/business world. You will have to
learn to influence people, to convince them to do things they aren't into. One
of the ways I know of is to do the pocket of excellence and make the team
dependent on your way of doing things, and then when they are dependent on it,
expand, and formalize it. The CI server is running in a VM on your
workstation. You just use it and set it up, and make sure everyone on the team
can access it. When they want a build, you send them a link to the URL for
your CruiseControl instance (o whatever CI tool). They want to fix a piece of
code you are in charge of? If they code a bug, make a unit test and ask them
to write code to make the test pass. Just set things up the way you want as
much as possible an force people to use it. Don't give them a choice. If yuo
try to have a discussion in which you envision people agreeing with your way
of doing things, that will never work. Just force them to move in the right
direction by doing it. Managers aren't as powerful as you might think. The
team generally does what they want. The worst that could happen is they ask
you to cease and desist, but they probably won't because they probably know
that you are a good contributor and they will have to put up with your desire
to do things "right".

That's it, basically is to keep trying, but don't try to argue verbally, just
put stuff in place and don't give people a choice, or you can find other
employment. Focus on small things, and 1-2 changes at a time, you don't want
to change everything at once.

Hope this helps.

------
moocow01
Personally I'd probably leave. I think there is a point where its healthy to
try to change the system but it sounds like you are fighting a current that is
too strong to encourage the way you want to work.

I believe you when you say your efforts are needed - the problem is management
very frequently has a hard time being able to understand that there is an
upfront cost that will eventually pay off. They are looking at spreadsheets
and just want to see that profit column keep on going up - you essentially are
proposing that the profit column should go down a bit (development costs) with
the promise that it will eventually go up much faster.

I've found that software companies either qet the necessity of quality/process
or don't (also some types of businesses do not really need much software
quality). Most of the time this is determined by if they have technical people
in the leadership ranks or not. By the hiring practices you listed Im guessing
they don't get how software quality and process impacts the bottom line.

My pessimistic view is that very little will change with the exception of
burning yourself out - sorry for the dire prediction Ive just been there
myself.

~~~
anonymous-dev
"Most of the time this is determined by if they have technical people in the
leadership ranks or not.", can you elaborate a bit on this ?

According to my experience, management has always viewed software as binary
world: it works or it does not.

About your last sentence, I was about to but gave myself a reason no to;
instead of trying to change things, I simply leave them the way they are and
stop "bitching" about it. Either way, I will see if good engineering practices
are really important or if a team can do without it (and what the potential
cost would be).

Now, my only focus is becoming good at spotting bugs, fixing them and
implementing features with fewest lines possible (a.k.a Spartan programming)
:)

~~~
bonobo
> "Most of the time this is determined by if they have technical people in the
> leadership ranks or not.", can you elaborate a bit on this ?

From my experience, non-technical managers often don't realize the importance
of these processes. Us programmers know how important is to control how the
codebase grows—when there are more than a few programmers touching the code,
and when the software keeps growing, a good test suite will prevent the team
from having to spend a lot of time trying to change something in the future
without breaking anything else (often in vain.)

I worked for both kind of people, those who understand and those who don't. I
found it was a huge PITA to work for people who don't understand, especially
if they can influence the hiring process. They will have a direct impact on
the culture of the team, and I don't believe a single developer can change
this alone.

This is just anecdotal, but the place where I worked for this kind of people
just closed the doors; the software grew to a point where it was unmaintanable
and, despite all my efforts to convince them on fixing things instead of
putting new features like mad, nobody ever listened. Now talk about
frustration...

Edit: of course I don't believe _every_ non-tech manager is like this. There
are those who, despite knowing about nothing when it comes to software
development, knows how to identify someone who does, hires this person and
trusts their opinion. Basically, people who know what they don't know.

------
freework
Don't worry about the process. Worry about the outcome of the process. Is the
site always down? Do you fail to ship? If so then you need to fix things.
Otherwise just let people work the way that lets them be most productive.

For instance, I'm not a fan of unit testing. I find that 99% of the time when
my tests fail, the failure is the test itself, not he code. WHen I'm forced to
write uni tests for everything, it slows me down greatly. I prefer to keep my
code clean and readable, instead of focusing on 100% code coverage. The same
principle applies to CI and other such "processes", in my experience. But
thats just me, everyone works their own way.

~~~
TheMonarch
I agree with this, if everything works with the company's current process,
there will be no way to convince people to change, and there wouldn't be any
reason to.

Try to maybe focus on fixing problems that your company actually has.

~~~
anonymous-dev
Will do that.

------
cemaphore
I recently quit my job for pretty much the same reasons. (I even created an
auto build system, too... weird.) I actually faced a professional development
dilemma: No forward progress. In an environment like that, where you have 20+
other people who don't care, aren't paying attention, just hack things
together... you're not going to make forward progress (professionally, and the
business will eventually be burdened with wanted growth and a messy code base,
or something will break big-time and cause major loss of revenue). They are
and they will continue to be stuck in the muck until someone closer to the top
most likely runs into a very hard decision, or looses a great deal of money
and has to face up to the reality of how they're building their business. I
recommend moving on. There's some positive to be said for being pragmatic
(sometimes you just have to hack it). However, if this culture is persistent,
it's a BAD culture, especially if they hire inexperienced / unqualified
people, and start teaching them these habits / traits (bad ju-ju for everyone,
the entire development world, when places operate like this).

------
codegeek
"Now, the business is doing well"

That is what matters to the decision makers in any business at the end of the
day. So if that is the case, you might not be able to convince the management.
Sure, your points are valid and I have the same frustration at work many times
but understand that management doesn't care about proper unit testing etc.
unless it impacts the business. As someone else pointed out, if you have
critical production bugs frequently causing loss (specifically monetary), then
you have a solid case to argue to change the process.

Not to say that you should just suck it up. I think it is worth to try and do
things the best way but just keep in mind that you should not expect
management to just do it because it is the right way to do it. So keep
expectations low but keep trying as well.

~~~
anonymous-dev
This reminds me of "Happiness = Expectations - results". You are spot on.

I think I mixed up my personal expectations (as a solo developer) with those
of my company. Will keep my work related expectations low and solo developer
related high.

------
devb0x
Lead by doing. Show what you're doing and why, and get others to support your
vision. Then it may be easier to get others do tackle some of the challenges
with you.

~~~
anonymous-dev
I did try that and it did not work. See explanation above.

